< draft-ietf-core-oscore-groupcomm-04.txt   draft-ietf-core-oscore-groupcomm-05.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: September 9, 2019 F. Palombini Expires: January 6, 2020 F. Palombini
Ericsson AB Ericsson AB
J. Park J. Park
Universitaet Duisburg-Essen Universitaet Duisburg-Essen
March 08, 2019 July 05, 2019
Group OSCORE - Secure Group Communication for CoAP Group OSCORE - Secure Group Communication for CoAP
draft-ietf-core-oscore-groupcomm-04 draft-ietf-core-oscore-groupcomm-05
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 September 9, 2019. This Internet-Draft will expire on January 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . 8 2.1. Management of Group Keying Material . . . . . . . . . . . 8
2.2. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 9 2.2. Wrap-Around of Partial IVs . . . . . . . . . . . . . . . 9
3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 9 3. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Updated external_aad . . . . . . . . . . . . . . . . . . 9 3.1. Updated external_aad . . . . . . . . . . . . . . . . . . 10
3.2. Use of the 'kid' Parameter . . . . . . . . . . . . . . . 10 3.1.1. Updated external_aad for Encryption . . . . . . . . . 10
3.3. Updated 'unprotected' Field . . . . . . . . . . . . . . . 10 3.1.2. Updated external_aad for Signing . . . . . . . . . . 11
4. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 10 3.2. Use of the 'kid' Parameter . . . . . . . . . . . . . . . 12
4.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 11 3.3. Updated 'unprotected' Field . . . . . . . . . . . . . . . 12
4.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 12 4. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 12
4.3. Examples of Compressed COSE Objects . . . . . . . . . . . 12 4.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 12
4.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 13
4.3. Examples of Compressed COSE Objects . . . . . . . . . . . 14
5. Message Binding, Sequence Numbers, Freshness and Replay 5. Message Binding, Sequence Numbers, Freshness and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 13 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Synchronization of Sender Sequence Numbers . . . . . . . 13 5.1. Synchronization of Sender Sequence Numbers . . . . . . . 15
6. Message Processing . . . . . . . . . . . . . . . . . . . . . 14 6. Message Processing . . . . . . . . . . . . . . . . . . . . . 16
6.1. Protecting the Request . . . . . . . . . . . . . . . . . 14 6.1. Protecting the Request . . . . . . . . . . . . . . . . . 16
6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 15 6.2. Verifying the Request . . . . . . . . . . . . . . . . . . 17
6.3. Protecting the Response . . . . . . . . . . . . . . . . . 15 6.3. Protecting the Response . . . . . . . . . . . . . . . . . 17
6.4. Verifying the Response . . . . . . . . . . . . . . . . . 16 6.4. Verifying the Response . . . . . . . . . . . . . . . . . 18
7. Responsibilities of the Group Manager . . . . . . . . . . . . 17 7. Responsibilities of the Group Manager . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Group-level Security . . . . . . . . . . . . . . . . . . 18 8.1. Group-level Security . . . . . . . . . . . . . . . . . . 20
8.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 18 8.2. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 21
8.3. Management of Group Keying Material . . . . . . . . . . . 19 8.3. Management of Group Keying Material . . . . . . . . . . . 21
8.4. Update of Security Context and Key Rotation . . . . . . . 19 8.4. Update of Security Context and Key Rotation . . . . . . . 22
8.5. Collision of Group Identifiers . . . . . . . . . . . . . 20 8.5. Collision of Group Identifiers . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8.6. Cross-group Message Injection . . . . . . . . . . . . . . 23
9.1. Counter Signature Parameters Registry . . . . . . . . . . 20 8.7. End-to-end Protection . . . . . . . . . . . . . . . . . . 24
9.2. Expert Review Instructions . . . . . . . . . . . . . . . 22 8.8. Security Context Establishment . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8.9. Master Secret . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 8.10. Replay Protection . . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 23 8.11. Client Aliveness . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Assumptions and Security Objectives . . . . . . . . 25 8.12. Cryptographic Considerations . . . . . . . . . . . . . . 26
A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 25 8.13. Message Segmentation . . . . . . . . . . . . . . . . . . 26
A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 26 8.14. Privacy Considerations . . . . . . . . . . . . . . . . . 26
Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Appendix C. Example of Group Identifier Format . . . . . . . . . 29 9.1. Counter Signature Parameters Registry . . . . . . . . . . 27
Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 30 9.2. Counter Signature Key Parameters Registry . . . . . . . . 29
Appendix E. Examples of Synchronization Approaches . . . . . . . 31 9.3. Expert Review Instructions . . . . . . . . . . . . . . . 32
E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 31 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 31 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
E.3. Challenge-Response Synchronization . . . . . . . . . . . 32 10.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix F. No Verification of Signatures . . . . . . . . . . . 33 Appendix A. Assumptions and Security Objectives . . . . . . . . 35
Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 34 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 35
G.1. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 34 A.2. Security Objectives . . . . . . . . . . . . . . . . . . . 37
G.2. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 35 Appendix B. List of Use Cases . . . . . . . . . . . . . . . . . 37
G.3. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 36 Appendix C. Example of Group Identifier Format . . . . . . . . . 40
G.4. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 36 Appendix D. Set-up of New Endpoints . . . . . . . . . . . . . . 41
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix E. Examples of Synchronization Approaches . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 E.1. Best-Effort Synchronization . . . . . . . . . . . . . . . 41
E.2. Baseline Synchronization . . . . . . . . . . . . . . . . 42
E.3. Challenge-Response Synchronization . . . . . . . . . . . 42
Appendix F. No Verification of Signatures . . . . . . . . . . . 44
Appendix G. Document Updates . . . . . . . . . . . . . . . . . . 44
G.1. Version -04 to -05 . . . . . . . . . . . . . . . . . . . 44
G.2. Version -03 to -04 . . . . . . . . . . . . . . . . . . . 45
G.3. Version -02 to -03 . . . . . . . . . . . . . . . . . . . 46
G.4. Version -01 to -02 . . . . . . . . . . . . . . . . . . . 46
G.5. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 47
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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][I-D.dijk-core-groupcomm-bis]
deployed devices benefit from a group communication model, for addresses use cases where deployed devices benefit from a group
example to reduce latencies, improve performance and reduce bandwidth communication model, for example to reduce latencies, improve
utilisation. Use cases include lighting control, integrated building performance and reduce bandwidth utilisation. Use cases include
control, software and firmware updates, parameter and configuration lighting control, integrated building control, software and firmware
updates, commissioning of constrained networks, and emergency updates, parameter and configuration updates, commissioning of
multicast (see Appendix B). Furthermore, [RFC7390] recognizes the constrained networks, and emergency multicast (see Appendix B).
importance to introduce a secure mode for CoAP group communication. Furthermore, [RFC7390] recognizes the importance to introduce a
This specification defines such a mode. secure mode for CoAP group communication. 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, replay protection and binding of to-end encryption, integrity, replay protection and binding of
response to request between a sender and a receipient, also in the response to request between a sender and a receipient, also in the
presence of intermediaries. To this end, a CoAP message is protected presence of intermediaries. To this end, a CoAP message is protected
by including its payload (if any), certain options, and header fields by including its payload (if any), certain options, and header fields
in a COSE object, which replaces the authenticated and encrypted in a COSE object, which replaces the authenticated and encrypted
skipping to change at page 4, line 13 skipping to change at page 4, line 29
approach defines how OSCORE should be used in a group communication approach defines how OSCORE should be used in a group communication
setting, so that end-to-end security is assured in the same way as setting, so that end-to-end security is assured in the same way as
OSCORE for unicast communication. That is, end-to-end security is OSCORE for unicast communication. That is, end-to-end security is
provided for CoAP multicast requests sent by a client to the group, provided for CoAP multicast requests sent by a client to the group,
and for related CoAP responses sent by multiple servers. Group and for related CoAP responses sent by multiple servers. Group
OSCORE provides source authentication of all CoAP messages exchanged OSCORE provides source authentication of all CoAP messages exchanged
within the group, by means of digital signatures produced through within the group, by means of digital signatures produced through
private keys of sender devices and embedded in the protected CoAP private keys of sender devices and embedded in the protected CoAP
messages. messages.
As in OSCORE, it is still possible to simultaneously rely on DTLS As defined in the latest [I-D.dijk-core-groupcomm-bis], Group OSCORE
[RFC6347] to protect hop-by-hop communication between a sender and a is the security protocol to use for applications that rely on CoAP
proxy (and vice versa), and between a proxy and a recipient (and vice group communication. As in OSCORE, it is still possible to
versa). Note that DTLS cannot be used to secure messages sent over simultaneously rely on DTLS [RFC6347] to protect hop-by-hop
multicast. 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
described in CoAP [RFC7252] including "endpoint", "client", "server", described in CoAP [RFC7252] including "endpoint", "client", "server",
"sender" and "recipient"; group communication for CoAP [RFC7390]; "sender" and "recipient"; group communication for CoAP
COSE and counter signatures [RFC8152]. [RFC7390][I-D.dijk-core-groupcomm-bis]; COSE and counter signatures
[RFC8152].
Readers are also expected to be familiar with the terms and concepts Readers are also expected to be familiar with the terms and concepts
for protection and processing of CoAP messages through OSCORE, such for protection and processing of CoAP messages through OSCORE, such
as "Security Context" and "Master Secret", defined in as "Security Context" and "Master Secret", defined in
[I-D.ietf-core-object-security]. [I-D.ietf-core-object-security].
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.
skipping to change at page 6, line 21 skipping to change at page 6, line 39
* A new parameter Counter Signature Parameters is included. * A new parameter Counter Signature Parameters is included.
This parameter identifies the parameters associated to the This parameter identifies the parameters associated to the
digital signature algorithm specified in the Counter Signature digital signature algorithm specified in the Counter Signature
Algorithm. This parameter MAY be empty and is immutable once Algorithm. This parameter MAY be empty and is immutable once
the Common Context is established. The exact structure of the Common Context is established. The exact structure of
this parameter depends on the value of Counter Signature this parameter depends on the value of Counter Signature
Algorithm, and is defined in the Counter Signature Parameters Algorithm, and is defined in the Counter Signature Parameters
Registry (see Section 9.1), where each entry indicates a Registry (see Section 9.1), where each entry indicates a
specified structure of the Counter Signature Parameters. specified structure of the Counter Signature Parameters.
* A new parameter Counter Signature Key Parameters is included.
This parameter identifies the parameters associated to the
keys used with 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 Key Parameters Registry (see Section 9.2), where
each entry indicates a specified structure of the Counter
Signature Key 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.
3. one Recipient Context for each distinct endpoint from which 3. one Recipient Context for each distinct endpoint from which
messages are received, used to process incoming messages. The messages are received, used to process incoming messages. The
recipient may generate the Recipient Context upon receiving an recipient may generate the Recipient Context upon receiving an
skipping to change at page 6, line 40 skipping to change at page 7, line 21
3. one Recipient Context for each distinct endpoint from which 3. one Recipient Context for each distinct endpoint from which
messages are received, used to process incoming messages. The messages are received, used to process incoming messages. The
recipient may generate the Recipient Context upon receiving an recipient may generate the Recipient Context upon receiving an
incoming message from another endpoint in the group for the first incoming message from another endpoint in the group for the first
time (see Section 6.2 and Section 6.4). Each Recipient Context time (see Section 6.2 and Section 6.4). Each Recipient Context
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. Note that each Recipient Context includes
a Replay Window, unless the recipient acts only as client and
hence processes only responses as incoming messages.
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 |
skipping to change at page 9, line 7 skipping to change at page 9, line 32
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.ietf-ace-key-groupcomm-oscore]. [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 An endpoint 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 incremented after sending each new message
incremented after each request. including a Partial IV. This is the case for all group requests, all
Observe notifications [RFC7641] and, optionally, any other response.
When this happens, the endpoint MUST NOT transmit further group When a wrap-around happens, the endpoint MUST NOT transmit further
requests until it has derived a new Sender Context, in order to avoid messages including a Partial IV until it has derived a new Sender
reusing nonces with the same keys. Context, in order to avoid reusing nonces with the same keys.
Furthermore, the endpoint SHOULD inform the Group Manager, that can Furthermore, the endpoint SHOULD inform the Group Manager, that can
take one of the following actions: take one of the following actions:
o The Group Manager renews the OSCORE Security Context in the group o The Group Manager renews the OSCORE Security Context in the group
(see Section 2.1). (see Section 2.1).
o The Group Manager provides a new Sender ID value to the endpoint o The Group Manager provides a new Sender ID value to the endpoint
that has experienced the wrap-around. Then, the endpoint derives that has experienced the wrap-around. Then, the endpoint derives
a new Sender Context using the new Sender ID, as described in a new Sender Context using the new Sender ID, as described in
skipping to change at page 9, line 41 skipping to change at page 10, line 20
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.
3.1. Updated external_aad 3.1. Updated external_aad
The external_aad in the Additional Authenticated Data (AAD) is The external_aad in the Additional Authenticated Data (AAD) is
extended with the counter signature algorithm and related parameters extended as follows. In particular, it has one structure used for
used to sign messages. In particular, compared with Section 5.4 of the encryption process producing the ciphertext, and one structure
used for the signing process producing the counter signature.
3.1.1. Updated external_aad for Encryption
The first external_aad structure used for the encryption process
producing the ciphertext (see Section 5.3 of [RFC8152]) includes also
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 [I-D.ietf-core-object-security], the 'algorithms' array in the
aad_array MUST also include: aad_array MUST also include:
o 'alg_countersign', which contains the Counter Signature Algorithm o 'alg_countersign', which contains the Counter Signature Algorithm
from the Common Context (see Section 2). This parameter has the from the Common Context (see Section 2). This parameter has the
value specified in the "Value" field of the Counter Signature value specified in the "Value" field of the Counter Signature
Parameters Registry (see Section 9.1) for this counter signature Parameters Registry (see Section 9.1) for this counter signature
algorithm. algorithm.
The 'algorithms' array in the aad_array MAY also include: The 'algorithms' array in the aad_array MAY also include:
o 'par_countersign', which contains the Counter Signature Parameters o 'par_countersign', which contains the Counter Signature Parameters
from the Common Context (see Section 2). This parameter contains from the Common Context (see Section 2). This parameter contains
the counter signature parameters encoded as specified in the the counter signature parameters encoded as specified in the
"Parameters" field of the Counter Signature Parameters Registry "Parameters" field of the Counter Signature Parameters Registry
(see Section 9.1), for the used counter signature algorithm. Note (see Section 9.1), for the used counter signature algorithm. Note
that if the Counter Signature Parameters in the Common Context is that if the Counter Signature Parameters in the Common Context is
empty, 'par_countersign' is not present. empty, 'par_countersign' is not present.
This external_aad structure is used both for the encryption process o 'par_countersign_key', which contains the Counter Signature Key
producing the ciphertext (see Section 5.3 of [RFC8152]) and for the Parameters from the Common Context (see Section 2). This
signing process producing the counter signature, as defined below. parameter contains the counter signature key parameters encoded as
specified in the "Parameters" field of the Counter Signature Key
Parameters Registry (see Section 9.2), for the used counter
signature algorithm. Note that if the Counter Signature Key
Parameters in the Common Context is empty, 'par_countersign_key'
is not present.
Thus, the following external_aad structure is used for the encryption
process producing the ciphertext (see Section 5.3 of [RFC8152]).
external_aad = bstr .cbor aad_array external_aad = bstr .cbor aad_array
aad_array = [ aad_array = [
oscore_version : uint, oscore_version : uint,
algorithms : [alg_aead : int / tstr , algorithms : [alg_aead : int / tstr ,
alg_countersign : int / tstr , alg_countersign : int / tstr ,
? par_countersign : any], ? par_countersign : any ,
? par_countersign_key : any],
request_kid : bstr,
request_piv : bstr,
options : bstr
]
3.1.2. Updated external_aad for Signing
The second external_aad structure used for the signing process
producing the counter signature as defined below includes also:
o the counter signature algorithm and related parameters used to
sign messages, encoded as in the external_aad structure defined in
Section 3.1.1;
o the value of the OSCORE Option included in the OSCORE message,
encoded as a binary string.
Thus, the following external_aad structure is used 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 ,
? par_countersign : any ,
? par_countersign_key : any],
request_kid : bstr, request_kid : bstr,
request_piv : bstr, request_piv : bstr,
OSCORE_option: bstr,
options : bstr options : bstr
] ]
Note for implementation: this requires the value of the OSCORE option
to be fully ready, before starting the signing process.
3.2. Use of the 'kid' Parameter 3.2. Use of the 'kid' Parameter
The value of the 'kid' parameter in the 'unprotected' field of The value of the 'kid' parameter in the 'unprotected' field of
response messages MUST be set to the Sender ID of the endpoint response messages MUST be set to the Sender ID of the endpoint
transmitting the message. That is, unlike in transmitting the message. 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, i.e. both requests and responses. present in all messages, i.e. both requests and responses.
3.3. Updated 'unprotected' Field 3.3. Updated 'unprotected' Field
The 'unprotected' field MUST additionally include the following The 'unprotected' field MUST additionally include the following
parameter: parameter:
o CounterSignature0 : its value is set to the counter signature of o CounterSignature0 : its value is set to the counter signature of
the COSE object, computed by the sender using its own private key the COSE object, computed by the sender using its own private key
as described in Appendix A.2 of [RFC8152]. In particular, the as described in Appendix A.2 of [RFC8152]. In particular, the
Sig_structure contains the external_aad as defined above and the Sig_structure contains the external_aad as defined in
ciphertext of the COSE_Encrypt0 object as payload. Section 3.1.2 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 14, line 25 skipping to change at page 16, line 17
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. confidentiality, source authentication, message integrity.
As per [RFC7252][RFC7390], group requests sent over multicast MUST be As per [RFC7252][RFC7390][I-D.dijk-core-groupcomm-bis], group
Non-Confirmable. Thus, senders should store their outgoing messages requests sent over multicast MUST be Non-Confirmable. Thus, senders
for an amount of time defined by the application and sufficient to should store their outgoing messages for an amount of time defined by
correctly handle possible retransmissions. However, this does not the application and sufficient to correctly handle possible
prevent the acknowledgment of Confirmable group requests in non- retransmissions. However, this does not prevent the acknowledgment
multicast environments. Besides, according to Section 5.2.3 of of Confirmable group requests in non-multicast environments.
[RFC7252], responses to Non-Confirmable group requests SHOULD be also Besides, according to Section 5.2.3 of [RFC7252], responses to Non-
Non-Confirmable. However, endpoints MUST be prepared to receive Confirmable group requests SHOULD be also Non-Confirmable. However,
Confirmable responses in reply to a Non-Confirmable group request. 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, it is RECOMMENDED that the recipient does not send back any case, it is RECOMMENDED that the recipient does not send back any
error message. This prevents servers from replying with multiple error message. This prevents servers from replying with multiple
error messages to a client sending a group request, so avoiding the error messages to a client sending a group request, so avoiding the
skipping to change at page 16, line 23 skipping to change at page 18, line 14
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. The client also checks whether it as described in Section 3. The client also checks whether it
previously received a secure response to this request, such that previously received a secure response to this request, such that
it was successfully verified and included the same Recipient ID it was successfully verified and it included the same Recipient ID
('kid') of the just received response. In case of positive match ('kid') of the just received response. If the check yields a
the client SHALL stop processing the response. If the received positive match and the response is not an Observe notification
[RFC7641] (i.e., it does not include an Observe Option), the
client SHALL stop processing the response. If the received
Recipient ID ('kid') does not match with any Recipient Context for Recipient ID ('kid') does not match with any Recipient Context for
the retrieved Gid ('kid context'), then the client creates a new the retrieved Gid ('kid context'), then the client creates a new
Recipient Context, initializes it according to Section 3 of 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
skipping to change at page 16, line 49 skipping to change at page 18, line 42
response to the request. response to the request.
o Additionally, if the used Recipient Context was created upon o Additionally, if the used Recipient Context was created upon
receiving this response and the message is not verified receiving this response and the message is not verified
successfully, the client MAY delete that Recipient Context. Such successfully, the client MAY delete that Recipient Context. Such
a configuration, which is specified by the application, would a configuration, which is specified by the application, would
prevent attackers from overloading the client's storage and prevent attackers from overloading the client's storage and
creating processing overhead on the client. creating processing overhead on the client.
Upon freeing up the Token value of a secure group request for Upon freeing up the Token value of a secure group request for
possible reuse [RFC7390], the client MUST delete the list of recorded possible reuse [RFC7390][I-D.dijk-core-groupcomm-bis], the client
Recipient IDs associated to that request (see step 5 above). 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 19, line 45
respective Security Context. respective Security Context.
10. Acting as key repository, in order to handle the public keys of 10. Acting as key repository, in order to handle the public keys of
the members of its OSCORE groups, and providing such public keys the members of its OSCORE groups, and providing such public keys
to other members of the same group upon request. The actual to other members of the same group upon request. The actual
storage of public keys may be entrusted to a separate secure storage of public keys may be entrusted to a separate secure
storage device. storage device.
8. Security Considerations 8. Security Considerations
The same security considerations from OSCORE (Section 11 of The same threat model discussed for OSCORE in Appendix D.1 of
[I-D.ietf-core-object-security]) apply to this specification. [I-D.ietf-core-object-security] holds for Group OSCORE. In addition,
Additional security aspects to be taken into account are discussed source authentication of messages is explicitly ensured by means of
below. counter signatures, as further discussed in Section 8.1.
The same considerations on supporting Proxy operations discussed for
OSCORE in Appendix D.2 of [I-D.ietf-core-object-security] hold for
Group OSCORE.
The same considerations on protected message fields for OSCORE
discussed in Appendix D.3 of [I-D.ietf-core-object-security] hold for
Group OSCORE.
The same considerations on uniqueness of (key, nonce) pairs for
OSCORE discussed in Appendix D.4 of [I-D.ietf-core-object-security]
hold for Group OSCORE. This is further discussed in Section 8.2.
The same considerations on unprotected message fields for OSCORE
discussed in Appendix D.5 of [I-D.ietf-core-object-security] hold for
Group OSCORE, with the following difference. The countersignature
included in a Group OSCORE message is computed also over the value of
the OSCORE option, which is part of the Additional Authenticated Data
used in the signing process. This is further discussed in
Section 8.6.
As discussed in Section 6.2.3 of [I-D.dijk-core-groupcomm-bis], Group
OSCORE addresses security attacks against CoAP listed in Sections
11.2-11.6 of [RFC7252], especially when mounted over IP multicast.
The rest of this section first discusses security aspects to be taken
into account when using Group OSCORE. Then it goes through aspects
covered in the security considerations of OSCORE (Section 12 of
[I-D.ietf-core-object-security]), and discusses how they hold when
Group OSCORE is used.
8.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
has the following implications. has the following implications.
o Messages are encrypted at a group level (group-level data o Messages are encrypted at a group level (group-level data
confidentiality), i.e. they can be decrypted by any member of the confidentiality), i.e. they can be decrypted by any member of the
group, but not by an external adversary or other external group, but not by an external adversary or other external
skipping to change at page 18, line 41 skipping to change at page 21, line 11
to take part in group communications, there is a risk that it behaves to take part in group communications, there is a risk that it behaves
inappropriately. For instance, it can forward the content of inappropriately. For instance, it can forward the content of
messages in the group to unauthorized entities. However, in many use messages in the group to unauthorized entities. However, in many use
cases, the devices in the group belong to a common authority and are cases, the devices in the group belong to a common authority and are
configured by a commissioner (see Appendix B), which results in a configured by a commissioner (see Appendix B), which results in a
practically limited risk and enables a prompt detection/reaction in practically limited risk and enables a prompt detection/reaction in
case of misbehaving. case of misbehaving.
8.2. Uniqueness of (key, nonce) 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.4 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 The case A in Appendix D.3 of [I-D.ietf-core-object-security] for o The case A in Appendix D.4 of [I-D.ietf-core-object-security]
messages including a Partial IV concerns only group requests, and concerns all group requests and responses including a Partial IV
same considerations from [I-D.ietf-core-object-security] apply (e.g. Observe notifications). In this case, same considerations
here as well. from [I-D.ietf-core-object-security] apply here as well.
o The case B in Appendix D.3 of [I-D.ietf-core-object-security] for o The case B in Appendix D.4 of [I-D.ietf-core-object-security]
messages not including a Partial IV concerns all group responses, concerns responses not including a Partial IV (e.g. single
and same considerations from [I-D.ietf-core-object-security] apply response to a group request). In this case, same considerations
here as well. from [I-D.ietf-core-object-security] apply here as well.
As a consequence, each message encrypted/decrypted with the same As a consequence, each message encrypted/decrypted with the same
Sender Key is processed by using a different (ID_PIV, PIV) pair. Sender Key is processed by using a different (ID_PIV, PIV) pair.
This means that nonces used by any fixed encrypting endpoint are This means that nonces used by any fixed encrypting endpoint are
unique. Thus, each message is processed with a different (key, unique. Thus, each message is processed with a different (key,
nonce) pair. nonce) pair.
8.3. Management of Group Keying Material 8.3. Management of Group Keying Material
The approach described in this specification should take into account The approach described in this specification should take into account
skipping to change at page 20, line 31 skipping to change at page 23, line 5
Identifiers of different groups to coincide. That can also happen if Identifiers of different groups to coincide. That can also happen if
the application can not guarantee unique Group Identifiers within a the application can not guarantee unique Group Identifiers within a
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.
8.6. Cross-group Message Injection
A same endpoint is allowed to and would likely use the same signature
key in multiple OSCORE groups, possibly administered by different
Group Managers. Also, the same endpoint can register several times
in the same group, getting multiple unique Sender IDs. This requires
that, when a sender endpoint sends a message to an OSCORE group using
a Sender ID, the countersignature included in the message is
explicitly bound also to that group and to the used Sender ID.
To this end, the countersignature of each message protected with
Group OSCORE is computed also over the value of the OSCORE option,
which is part of the Additional Authenticated Data used in the
signing process (see Section 3.1.2). That is, the countersignature
is computed also over: the ID Context (Group ID) and the Partial IV,
which are always present in group requests; as well as the Sender ID
of the message originator, which is always present in all group
requests and responses.
Since the signing process takes as input also the ciphertext of the
COSE_Encrypt0 object, the countersignature is bound not only to the
intended OSCORE group, hence to the triplet (Master Secret, Master
Salt, ID Context), but also to a specific Sender ID in that group and
to its specific symmetric key used for AEAD encryption, hence to the
quartet (Master Secret, Master Salt, ID Context, Sender ID).
This makes it practically infeasible to perform the attack described
below, where a malicious group member injects forged messages to a
different OSCORE group than the originally intended one. Let us
consider:
o Two OSCORE groups G1 and G2, with ID Context (Group ID) Gid1 and
Gid2, respectively. Both G1 and G2 use the AEAD cipher AES-CCM-
16-64-128, i.e. the MAC of the ciphertext is 8 bytes in size.
o A victim endpoint V which is member of both G1 and G2, and uses
the same signature key in both groups. The endpoint V has Sender
ID Sid1 in G1 and Sender ID Sid2 in G2. The pairs (Sid1, Gid1)
and (Sid2, Gid2) identify the same public key of V in G1 and G2,
respectively.
o A malicious endpoint Z is also member of both G1 and G2. Hence, Z
is able to derive the symmetric keys associated to V in G1 and G2.
If countersignatures were not computed also over the value of the
OSCORE option as discussed above, Z can intercept a group message M1
sent by V to G1, and forge a valid signed message M2 to be injected
in G2, making it appear as sent by V and valid to be accepted.
More in detail, Z first intercepts a message M1 sent by V in G1, and
tries to forge a message M2, by changing the value of the OSCORE
option from M1 as follows: the 'kid context' is changed from G1 to
G2; and the 'kid' is changed from Sid1 to Sid2.
If M2 is used as a request message, there is a probability equal to
2^-64 that the same unchanged MAC is successfully verified by using
Sid2 as 'request_kid' and the symmetric key associated to V in G2.
In such a case, the same unchanged signature would be also valid.
Note that Z can check offline if a performed forgery is actually
valid before sending the forged message to G2. That is, this attack
has a complexity of 2^64 offline calculations.
If M2 is used as a response, Z can also change the response Partial
IV, until the same unchanged MAC is successfully verified by using
Sid2 as 'request_kid' and the symmetric key associated to V in G2.
In such a case, the same unchanged signature would be also valid.
Since the Partial IV is 5 bytes in size, this requires 2^40
operations to test all the Partial IVs, which can be done in real-
time. Also, the probability that a single given message M1 can be
used to forge a response M2 for a given request is equal to 2^-24,
since there are more MAC values (8 bytes in size) than Partial IV
values (5 bytes in size).
Note that, by changing the Partial IV as discussed above, any member
of G1 would also be able to forge a valid signed response message M2
to be injected in G1.
8.7. End-to-end Protection
The same considerations from Section 12.1 of
[I-D.ietf-core-object-security] hold for Group OSCORE.
Additionally, (D)TLS and Group OSCORE can be combined for protecting
message exchanges occurring over unicast. Instead, it is not
possible to combine DTLS and Group OSCORE for protecting message
exchanges where messages are (also) sent over multicast.
8.8. Security Context Establishment
The use of COSE_Encrypt0 and AEAD to protect messages as specified in
this document requires an endpoint to be a member of an OSCORE group.
That is, upon joining the group, the endpoint securely receives from
the Group Manager the necessary input parameters, which are used to
derive the Common Security Context and the Sender Context (see
Section 2). The Group Manager ensures uniqueness of Sender IDs in
the same group.
Each different Recipient Context for decrypting messages from a
particular sender can be derived at runtime, at the latest upon
receiving a message from that sender for the first time.
Countersignatures of group messages are verified by means of the
public key of the respective sender endpoint. Upon nodes' joining,
the Group Manager collects such public keys and MUST verify proof-of-
possession of the respective private key. Later on, a group member
can request from the Group Manager the public keys of other group
members.
The joining process can occur, for instance, as defined in
[I-D.ietf-ace-key-groupcomm-oscore].
8.9. Master Secret
Group OSCORE derives the Security Context using the same construction
of OSCORE, and by using the Group Identifier of a group as the
related ID Context. Hence, the same required properties of the
Security Context parameters discussed in Section 3.3 of
[I-D.ietf-core-object-security] hold for this document.
With particular reference to the OSCORE Master Secret, it has to be
kept secret among the members of the respective OSCORE group and the
Group Manager responsible for that group. Also, the Master Secret
must have a good amount of randomness, and the Group Manager can
generate it offline using a good random number generator. This
includes the case where the Group Manager rekeys the group by
generating and distributing a new Master Secret. Randomness
requirements for security are described in [RFC4086].
8.10. Replay Protection
As in OSCORE, also Group OSCORE relies on sender sequence numbers
included in the COSE message field 'Partial IV' and used to build
AEAD nonces.
As discussed in Section 5.1, an endpoint that has just joined a group
is exposed to replay attack, as it is not aware of the sender
sequence numbers currently used by other group members. Appendix E
describes how endpoints can synchronize with senders' sequence
numbers.
Unless exchanges in a group rely only on unicast messages, Group
OSCORE cannot be used with reliable transport. Thus, other that in
such unlikely case, it cannot be defined that only messages with
sequence number which are equal to previous sequence number + 1 are
accepted.
The processing of response messages described in Section 6.4 also
ensures that a client accepts a single valid response to a given
request from each replying server, unless CoAP observation is used.
8.11. Client Aliveness
As discussed in Section 12.5 of [I-D.ietf-core-object-security], a
server may use the Echo option [I-D.ietf-core-echo-request-tag] to
verify the aliveness of the client that originated a received
request. This would also allow the server to (re-)synchronize with
the client's sequence number, as well as to ensure that the request
is fresh and has not been replayed or (purposely) delayed, if it is
the first one received from that client after having joined the group
or rebooted (see Appendix E.3).
8.12. Cryptographic Considerations
The same considerations from Section 12.6 of
[I-D.ietf-core-object-security] about the maximum Sender Sequence
Number hold for Group OSCORE.
As discussed in Section 2.2, an endpoint that experiences a wrap-
around of its own Sender Sequence Number MUST NOT transmit further
messages including a Partial IV, until it has derived a new Sender
Context. This prevents the endpoint to reuse the same AEAD nonces
with the same Sender key.
In order to renew its own Sender Context, the endpoint SHOULD inform
the Group Manager, which can either renew the whole OSCORE Security
Context by means of group rekeying, or provide only that endpoint
with a new Sender ID value. Either case, the endpoint derives a new
Sender Context, and in particular a new Sender Key.
Additionally, the same considerations from Section 12.6 of
[I-D.ietf-core-object-security] hold for Group OSCORE, about building
the AEAD nonce and the secrecy of the Security Context parameters.
8.13. Message Segmentation
The same considerations from Section 12.7 of
[I-D.ietf-core-object-security] hold for Group OSCORE.
8.14. Privacy Considerations
Group OSCORE ensures end-to-end integrity protection and encryption
of the message payload and all options that are not used for proxy
operations. In particular, options are processed according to the
same class U/I/E that they have for OSCORE. Therefore, the same
privacy considerations from Section 12.8 of
[I-D.ietf-core-object-security] hold for Group OSCORE.
Furthermore, the following privacy considerations hold, about the
OSCORE option that may reveal information on the communicating
endpoints.
o The 'kid' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, may reveal
information about the Sender Endpoint. Since both requests and
responses always include the 'kid' parameter, this may reveal
information about both a client sending a group request and all
the possibly replying servers sending their own individual
response.
o The 'kid context' parameter, which is intended to help a recipient
endpoint to find the right Recipient Context, reveals information
about the sender endpoint. In particular, it reveals that the
sender endpoint is a member of a particular OSCORE group, whose
current Group ID is indicated in the 'kid context' parameter.
Moreover, this parameter explicitly relate two or more
communicating endpoints, as members of the same OSCORE group.
Also, using the mechanisms described in Appendix E.3 to achieve
sequence number synchronization with a client may reveal when a
server device goes through a reboot. This can be mitigated by the
server device storing the precise state of the replay window of each
known client on a clean shutdown.
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 and delete this Document]" with the RFC number of this specification and delete this
paragraph. paragraph.
This document has the following actions for IANA. This document has the following actions for IANA.
9.1. Counter Signature Parameters Registry 9.1. Counter Signature Parameters Registry
This specification establishes the IANA "Counter Signature This specification establishes the IANA "Counter Signature
Parameters" Registry. The Registry has been created to use the Parameters" Registry. The Registry has been created to use the
"Expert Review Required" registration procedure [RFC8126]. Expert "Expert Review Required" registration procedure [RFC8126]. Expert
review guidelines are provided in Section 9.2. review guidelines are provided in Section 9.3.
The columns of this table are: The columns of this table are:
o Name: A value that can be used to identify an algorithm in o Name: A value that can be used to identify an algorithm in
documents for easier comprehension. Its value is taken from the documents for easier comprehension. Its value is taken from the
'Name' column of the "COSE Algorithms" Registry. 'Name' column of the "COSE Algorithms" Registry.
o Value: The value to be used to identify this algorithm. Its o Value: The value to be used to identify this algorithm. Its
content is taken from the 'Value' column of the "COSE Algorithms" content is taken from the 'Value' column of the "COSE Algorithms"
Registry. The value MUST be the same one used in the "COSE Registry. The value MUST be the same one used in the "COSE
skipping to change at page 21, line 22 skipping to change at page 28, line 26
field. field.
o Description: A short description of the parameters encoded in the o Description: A short description of the parameters encoded in the
'Parameters' field (if any). 'Parameters' field (if any).
o Reference: This contains a pointer to the public specification for o Reference: This contains a pointer to the public specification for
the field, if one exists. the field, if one exists.
Initial entries in the registry are as follows. Initial entries in the registry are as follows.
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| Name | Value | Parameters | Description | Reference | | Name | Value | Parameters | Description | Reference |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| EdDSA | -8 | crv : int | crv value taken | [This | | EdDSA | -8 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] | | | | | from the COSE | Document] |
| | | | Elliptic Curve | | | | | | Elliptic Curve | |
| | | | Registry | | | | | | Registry | |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| ES256 | -7 | crv : int | crv value taken | [This | | ES256 | -7 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] | | | | | from the COSE | Document] |
| | | | Elliptic Curve | | | | | | Elliptic Curve | |
| | | | Registry | | | | | | Registry | |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| ES384 | -35 | crv : int | crv value taken | [This | | ES384 | -35 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] | | | | | from the COSE | Document] |
| | | | Elliptic Curve | | | | | | Elliptic Curve | |
| | | | Registry | | | | | | Registry | |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| ES512 | -36 | crv : int | crv value taken | [This | | ES512 | -36 | crv : int | crv value taken | [This |
| | | | from the COSE | Document] | | | | | from the COSE | Document] |
| | | | Elliptic Curve | | | | | | Elliptic Curve | |
| | | | Registry | | | | | | Registry | |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| PS256 | -37 | | Parameters not | [This | | PS256 | -37 | | Parameters not | [This |
| | | | present | Document] | | | | | present | Document] |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| PS384 | -38 | | Parameters not | [This | | PS384 | -38 | | Parameters not | [This |
| | | | present | Document] | | | | | present | Document] |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| PS512 | -39 | | Parameters not | [This | | PS512 | -39 | | Parameters not | [This |
| | | | present | Document] | | | | | present | Document] |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| RSAES-OAEP | -40 | | Parameters not | [This | | RSAES-OAEP | -40 | | Parameters not | [This |
| w/ RFC 8017 | | | present | Document] | | w/ RFC 8017 | | | present | Document] |
| default | | | | | | default | | | | |
| parameters | | | | | | parameters | | | | |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| RSAES-OAEP | -41 | | Parameters not | [This | | RSAES-OAEP | -41 | | Parameters not | [This |
| w/ SHA-256 | | | present | Document] | | w/ SHA-256 | | | present | Document] |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
| | | | | | | | | | | |
| RSAES-OAEP | -42 | | Parameters not | [This | | RSAES-OAEP | -42 | | Parameters not | [This |
| w/ SHA-512 | | | present | Document] | | w/ SHA-512 | | | present | Document] |
| | | | | | | | | | | |
+-------------+-------+-------------+-----------------+-----------+ +-------------+-------+--------------+-----------------+-----------+
9.2. Expert Review Instructions 9.2. Counter Signature Key Parameters Registry
The IANA Registry established in this document is defined as expert This specification establishes the IANA "Counter Signature Key
review. This section gives some general guidelines for what the Parameters" Registry. The Registry has been created to use the
"Expert Review Required" registration procedure [RFC8126]. Expert
review guidelines are provided in Section 9.3.
The columns of this table are:
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 key 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 | kty : int | kty value is 1, | [This |
| | | | as Key Type "OKP" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
| | | | | |
| | | crv : int | crv value taken | |
| | | | from the COSE | |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| ES256 | -7 | kty : int | kty value is 2, | [This |
| | | | as Key Type "EC2" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
| | | | | |
| | | crv : int | crv value taken | |
| | | | from the COSE | |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| ES384 | -35 | kty : int | kty value is 2, | [This |
| | | | as Key Type "EC2" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
| | | crv : int | crv value taken | |
| | | | from the COSE | |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| ES512 | -36 | kty : int | kty value is 2, | [This |
| | | | as Key Type "EC2" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
| | | crv : int | crv value taken | |
| | | | from the COSE | |
| | | | Elliptic Curve | |
| | | | Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| PS256 | -37 | kty : int | kty value is 3, | [This |
| | | | as Key Type "RSA" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| PS384 | -38 | kty : int | kty value is 3, | [This |
| | | | as Key Type "RSA" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| PS512 | -39 | kty : int | kty value is 3, | [This |
| | | | as Key Type "RSA" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| RSAES-OAEP | -40 | kty : int | kty value is 3, | [This |
| w/ RFC 8017 | | | as Key Type "RSA" | Document] |
| default | | | from the COSE Key | |
| parameters | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| RSAES-OAEP | -41 | kty : int | kty value is 3, | [This |
| w/ SHA-256 | | | as Key Type "RSA" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
| | | | | |
| RSAES-OAEP | -42 | kty : int | kty value is 3, | [This |
| w/ SHA-512 | | | as Key Type "RSA" | Document] |
| | | | from the COSE Key | |
| | | | Types Registry | |
| | | | | |
+-------------+-------+--------------+-------------------+-----------+
9.3. 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 should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude. experts for a reason so they should be given substantial latitude.
Expert reviewers should take into consideration the following points: Expert reviewers should take into consideration the following points:
TBD o Clarity and correctness of registrations. Experts are expected to
check the clarity of purpose and use of the requested entries.
Experts should inspect the entry for the algorithm considered, to
verify the conformity of the encoding proposed against the
theoretical algorithm, including completeness of the 'Parameters'
column. Expert needs to make sure values are taken from the right
registry, when that's required. Expert should consider requesting
an opinion on the correctness of registered parameters from the
CBOR Object Signing and Encryption Working Group (COSE).
Encodings that do not meet these objective of clarity and
completeness should not be registered.
o Duplicated registration and point squatting should be discouraged.
Reviewers are encouraged to get sufficient information for
registration requests to ensure that the usage is not going to
duplicate one that is already registered and that the point is
likely to be used in deployments.
o Experts should take into account the expected usage of fields when
approving point assignment. The length of the 'Parameters'
encoding should be weighed against the usage of the entry,
considering the size of device it will be used on. Additionally,
the length of the encoded value should be weighed against how many
code points of that length are left, the size of device it will be
used on, and the number of code points left that encode to that
size.
o Specifications are recommended. When specifications are not
provided, the description provided needs to have sufficient
information to verify the points above.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.dijk-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", draft-
dijk-core-groupcomm-bis-00 (work in progress), March 2019.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-16 (work in (OSCORE)", draft-ietf-core-object-security-16 (work in
progress), March 2019. 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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 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>.
skipping to change at page 24, line 8 skipping to change at page 34, line 28
[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] [I-D.ietf-ace-key-groupcomm-oscore]
Tiloca, M., Park, J., and F. Palombini, "Key Management Tiloca, M., Park, J., and F. Palombini, "Key Management
for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
oscore-00 (work in progress), December 2018. oscore-01 (work in progress), March 2019.
[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-22 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019. (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, "CoAP: Echo,
Request-Tag", draft-ietf-core-echo-request-tag-03 (work in Request-Tag, and Token Processing", draft-ietf-core-echo-
progress), October 2018. request-tag-05 (work in progress), May 2019.
[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.
[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,
skipping to change at page 27, line 32 skipping to change at page 37, line 50
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. In accordance with OSCORE messages coming from a single sender. In accordance with 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 senders. 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][I-D.dijk-core-groupcomm-bis]
background for multicast-based CoAP communication, with particular provides the necessary background for multicast-based CoAP
reference to low-power and lossy networks (LLNs) and resource communication, with particular reference to low-power and lossy
constrained environments. The interested reader is encouraged to networks (LLNs) and resource constrained environments. The
first read [RFC7390] to understand the non-security related details. interested reader is encouraged to first read
This section discusses a number of use cases that benefit from secure [RFC7390][I-D.dijk-core-groupcomm-bis] to understand the non-security
group communication. Specific security requirements for these use related details. This section discusses a number of use cases that
cases are discussed in Appendix A. benefit from secure group communication. Specific security
requirements for these use cases are discussed in Appendix A.
o Lighting control: consider a building equipped with IP-connected o Lighting control: consider a building equipped with IP-connected
lighting devices, switches, and border routers. The devices are lighting devices, switches, and border routers. The devices are
organized into groups according to their physical location in the organized into groups according to their physical location in the
building. For instance, lighting devices and switches in a room building. For instance, lighting devices and switches in a room
or corridor can be configured as members of a single group. or corridor can be configured as members of a single group.
Switches are then used to control the lighting devices by sending Switches are then used to control the lighting devices by sending
on/off/dimming commands to all lighting devices in a group, while on/off/dimming commands to all lighting devices in a group, while
border routers connected to an IP network backbone (which is also border routers connected to an IP network backbone (which is also
multicast-enabled) can be used to interconnect routers in the multicast-enabled) can be used to interconnect routers in the
skipping to change at page 29, line 45 skipping to change at page 40, line 16
and local information related to the ongoing emergency. This kind and local information related to the ongoing emergency. This kind
of setups should additionally rely on a fault tolerance multicast of setups should additionally rely on a fault tolerance multicast
algorithm, such as MPL. algorithm, such as MPL.
Appendix C. Example of Group Identifier Format Appendix C. Example of Group Identifier Format
This section provides an example of how the Group Identifier (Gid) This section provides an example of how the Group Identifier (Gid)
can be specifically formatted. That is, the Gid can be composed of can be specifically formatted. That is, the Gid can be composed of
two parts, namely a Group Prefix and a Group Epoch. two parts, namely a Group Prefix and a Group Epoch.
The Group Prefix is constant over time and is uniquely defined in the For each group, the Group Prefix is constant over time and is
set of all the groups associated to the same Group Manager. The uniquely defined in the set of all the groups associated to the same
choice of the Group Prefix for a given group's Security Context is Group Manager. The choice of the Group Prefix for a given group's
application specific. The size of the Group Prefix directly impact Security Context is application specific. The size of the Group
on the maximum number of distinct groups under the same Group Prefix directly impact on the maximum number of distinct groups under
Manager. the same Group Manager.
The Group Epoch is set to 0 upon the group's initialization, and is The Group Epoch is set to 0 upon the group's initialization, and is
incremented by 1 upon completing each renewal of the Security Context incremented by 1 upon completing each renewal of the Security Context
and keying material in the group (see Section 2.1). In particular, and keying material in the group (see Section 2.1). In particular,
once a new Master Secret has been distributed to the group, all the once a new Master Secret has been distributed to the group, all the
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)
skipping to change at page 34, line 28 skipping to change at page 44, line 43
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 -03 to -04 G.1. Version -04 to -05
o Added references to draft-dijk-core-groupcomm-bis.
o New parameter Counter Signature Key Parameters (Section 2).
o Clarification about Recipient COntexts (Section 2).
o Two different external_aad for encrypting and signing
(Section 3.1).
o Updated response verification to handle Observe notifications
(Section 6.4).
o Extended Security Considerations (Section 8).
o New "Counter Signature Key Parameters" IANA Registry
(Section 9.2).
G.2. Version -03 to -04
o Added the new "Counter Signature Parameters" in the Security o Added the new "Counter Signature Parameters" in the Security
Common Context (see Section 2). Common Context (see Section 2).
o Added recommendation on using "deterministic ECDSA" if ECDSA is o Added recommendation on using "deterministic ECDSA" if ECDSA is
used as counter signature algorithm (see Section 2). used as counter signature algorithm (see Section 2).
o Clarified possible asynchronous retrieval of key material from the o Clarified possible asynchronous retrieval of key material from the
Group Manager, in order to process incoming messages (see Group Manager, in order to process incoming messages (see
Section 2). Section 2).
skipping to change at page 35, line 26 skipping to change at page 46, line 8
o Handling of just created Recipient Contexts in case of o Handling of just created Recipient Contexts in case of
unsuccessful message verification (see Sections 6.2 and 6.4). unsuccessful message verification (see Sections 6.2 and 6.4).
o Handling of replied/repeated responses on the client (see o Handling of replied/repeated responses on the client (see
Section 6.4). Section 6.4).
o New IANA Registry "Counter Signature Parameters" (see o New IANA Registry "Counter Signature Parameters" (see
Section 9.1). Section 9.1).
G.2. Version -02 to -03 G.3. 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 36, line 11 skipping to change at page 46, line 42
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.3. Version -01 to -02 G.4. 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 36, line 46 skipping to change at page 47, line 29
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.4. Version -00 to -01 G.5. 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.
 End of changes. 44 change blocks. 
199 lines changed or deleted 724 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/