draft-ietf-core-observe-multicast-notifications-00.txt   draft-ietf-core-observe-multicast-notifications-01.txt 
CoRE Working Group M. Tiloca CoRE Working Group M. Tiloca
Internet-Draft R. Hoeglund Internet-Draft R. Höglund
Updates: 7252, 7641 (if approved) RISE AB Updates: 7252, 7641 (if approved) RISE AB
Intended status: Standards Track C. Amsuess Intended status: Standards Track C. Amsüss
Expires: 3 October 2021 Expires: 13 January 2022
F. Palombini F. Palombini
Ericsson AB Ericsson AB
1 April 2021 12 July 2021
Observe Notifications as CoAP Multicast Responses Observe Notifications as CoAP Multicast Responses
draft-ietf-core-observe-multicast-notifications-00 draft-ietf-core-observe-multicast-notifications-01
Abstract Abstract
The Constrained Application Protocol (CoAP) allows clients to The Constrained Application Protocol (CoAP) allows clients to
"observe" resources at a server, and receive notifications as unicast "observe" resources at a server, and receive notifications as unicast
responses upon changes of the resource state. In some use cases, responses upon changes of the resource state. In some use cases,
such as based on publish-subscribe, it would be convenient for the such as based on publish-subscribe, it would be convenient for the
server to send a single notification addressed to all the clients server to send a single notification addressed to all the clients
observing a same target resource. This document updates RFC7252 and observing a same target resource. This document updates RFC7252 and
RFC7641, and defines how a server sends observe notifications as RFC7641, and defines how a server sends observe notifications as
response messages over multicast, synchronizing all the observers of response messages over multicast, synchronizing all the observers of
a same resource on a same shared Token value. Besides, this document a same resource on a same shared Token value. Besides, this document
defines how Group OSCORE can be used to protect multicast defines how Group OSCORE can be used to protect multicast
notifications end-to-end between the server and the observer clients. notifications end-to-end between the server and the observer clients.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Constrained RESTful
Environments Working Group mailing list (core@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/core/.
Source for this draft and an issue tracker can be found at
https://github.com/core-wg/observe-multicast-notifications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 3 October 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 5 2. Server-Side Requirements . . . . . . . . . . . . . . . . . . 6
2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Informative Response . . . . . . . . . . . . . . . . . . 7 2.2. Informative Response . . . . . . . . . . . . . . . . . . 7
2.2.1. Encoding of Transport-Specific Message Information . 8 2.2.1. Encoding of Transport-Specific Message Information . 9
2.2.2. Encoding of Transport-Independent Message 2.2.2. Encoding of Transport-Independent Message
Information . . . . . . . . . . . . . . . . . . . . . 11 Information . . . . . . . . . . . . . . . . . . . . . 12
2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13 2.4. Congestion Control . . . . . . . . . . . . . . . . . . . 13
2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . 14
3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14 3. Client-Side Requirements . . . . . . . . . . . . . . . . . . 14
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Informative Response . . . . . . . . . . . . . . . . . . 14 3.2. Informative Response . . . . . . . . . . . . . . . . . . 14
3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Notifications . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16 3.4. Cancellation . . . . . . . . . . . . . . . . . . . . . . 16
4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 16
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Rough Counting of Clients in the Group Observation . . . . . 19 6. Rough Counting of Clients in the Group Observation . . . . . 19
6.1. Processing on the Client Side . . . . . . . . . . . . . . 20 6.1. Multicast-Response-Feedback-Divider Option . . . . . . . 19
6.2. Processing on the Server Side . . . . . . . . . . . . . . 21 6.2. Processing on the Client Side . . . . . . . . . . . . . . 20
6.2.1. Request for Feedback . . . . . . . . . . . . . . . . 21 6.3. Processing on the Server Side . . . . . . . . . . . . . . 21
6.2.2. Collection of Feedback . . . . . . . . . . . . . . . 21 6.3.1. Request for Feedback . . . . . . . . . . . . . . . . 21
6.2.3. Processing of Feedback . . . . . . . . . . . . . . . 22 6.3.2. Collection of Feedback . . . . . . . . . . . . . . . 22
7. Protection of Multicast Notifications with Group OSCORE . . . 23 6.3.3. Processing of Feedback . . . . . . . . . . . . . . . 22
7.1. Signaling the OSCORE Group in the Informative Response . 24
7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 26 7. Protection of Multicast Notifications with Group OSCORE . . . 24
7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 26 7.1. Signaling the OSCORE Group in the Informative Response . 25
7.2.2. Informative Response . . . . . . . . . . . . . . . . 27 7.2. Server-Side Requirements . . . . . . . . . . . . . . . . 27
7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 27 7.2.1. Registration . . . . . . . . . . . . . . . . . . . . 27
7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 28 7.2.2. Informative Response . . . . . . . . . . . . . . . . 28
7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 28 7.2.3. Notifications . . . . . . . . . . . . . . . . . . . . 28
7.3.1. Informative Response . . . . . . . . . . . . . . . . 28 7.2.4. Cancellation . . . . . . . . . . . . . . . . . . . . 29
7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 29 7.3. Client-Side Requirements . . . . . . . . . . . . . . . . 29
8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 30 7.3.1. Informative Response . . . . . . . . . . . . . . . . 29
9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 34 7.3.2. Notifications . . . . . . . . . . . . . . . . . . . . 30
10. Intermediaries Together with End-to-End Security . . . . . . 35 8. Example with Group OSCORE . . . . . . . . . . . . . . . . . . 31
10.1. The Listen-To-Multicast-Responses Option . . . . . . . . 36 9. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 35
10.2. Message Processing . . . . . . . . . . . . . . . . . . . 37 10. Intermediaries Together with End-to-End Security . . . . . . 36
11. Informative Response Parameters . . . . . . . . . . . . . . . 39 10.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 37
12. Transport Protocol Information . . . . . . . . . . . . . . . 40 10.2. Message Processing . . . . . . . . . . . . . . . . . . . 38
11. Informative Response Parameters . . . . . . . . . . . . . . . 40
12. Transport Protocol Information . . . . . . . . . . . . . . . 41
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 13. Security Considerations . . . . . . . . . . . . . . . . . . . 41
13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 41 13.1. Listen-To-Multicast-Responses Option . . . . . . . . . . 42
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
14.1. Media Type Registrations . . . . . . . . . . . . . . . . 42 14.1. Media Type Registrations . . . . . . . . . . . . . . . . 43
14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 43 14.2. CoAP Content-Formats Registry . . . . . . . . . . . . . 44
14.3. Informative Response Parameters Registry . . . . . . . . 43 14.3. Informative Response Parameters Registry . . . . . . . . 44
14.4. CoAP Transport Information Registry . . . . . . . . . . 44 14.4. CoAP Transport Information Registry . . . . . . . . . . 45
14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45 14.5. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45
14.6. Expert Review Instructions . . . . . . . . . . . . . . . 45 14.6. Expert Review Instructions . . . . . . . . . . . . . . . 46
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
15.1. Normative References . . . . . . . . . . . . . . . . . . 46 15.1. Normative References . . . . . . . . . . . . . . . . . . 46
15.2. Informative References . . . . . . . . . . . . . . . . . 48 15.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Different Sources for Group Observation Data . . . . 50 Appendix A. Different Sources for Group Observation Data . . . . 51
A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 50 A.1. Topic Discovery in Publish-Subscribe Settings . . . . . . 51
A.2. Introspection at the Multicast Notification Sender . . . 51 A.2. Introspection at the Multicast Notification Sender . . . 52
Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 52 Appendix B. Pseudo-Code for Rough Counting of Clients . . . . . 53
B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 52 B.1. Client Side . . . . . . . . . . . . . . . . . . . . . . . 53
B.2. Client Side - Optimized Version . . . . . . . . . . . . . 53 B.2. Client Side - Optimized Version . . . . . . . . . . . . . 54
B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 54 B.3. Server Side . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 56 Appendix C. OSCORE Group Self-Managed by the Server . . . . . . 57
Appendix D. Phantom Request as Deterministic Request . . . . . . 58 Appendix D. Phantom Request as Deterministic Request . . . . . . 60
Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 59 Appendix E. Example with a Proxy . . . . . . . . . . . . . . . . 60
Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 61 Appendix F. Example with a Proxy and Group OSCORE . . . . . . . 63
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 67 Appendix G. Example with a Proxy and Deterministic Requests . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 G.1. Assumptions and Walkthrough . . . . . . . . . . . . . . . 69
G.2. Message Exchange . . . . . . . . . . . . . . . . . . . . 71
Appendix H. Document Updates . . . . . . . . . . . . . . . . . . 76
H.1. Version -00 to -01 . . . . . . . . . . . . . . . . . . . 76
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 76
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] has been The Constrained Application Protocol (CoAP) [RFC7252] has been
extended with a number of mechanisms, including resource Observation extended with a number of mechanisms, including resource Observation
[RFC7641]. This enables CoAP clients to register at a CoAP server as [RFC7641]. This enables CoAP clients to register at a CoAP server as
"observers" of a resource, and hence being automatically notified "observers" of a resource, and hence being automatically notified
with an unsolicited response upon changes of the resource state. with an unsolicited response upon changes of the resource state.
CoAP supports group communication over IP multicast CoAP supports group communication over IP multicast
skipping to change at page 4, line 25 skipping to change at page 4, line 44
can benefit of observation for discovering (to-be-created) OSCORE can benefit of observation for discovering (to-be-created) OSCORE
groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the groups [I-D.ietf-core-oscore-groupcomm], by retrieving from the
Resource Directory updated links and descriptions to join them Resource Directory updated links and descriptions to join them
through the respective Group Manager through the respective Group Manager
[I-D.tiloca-core-oscore-discovery]. [I-D.tiloca-core-oscore-discovery].
More in general, multicast notifications would be beneficial whenever More in general, multicast notifications would be beneficial whenever
several CoAP clients observe a same target resource at a CoAP server, several CoAP clients observe a same target resource at a CoAP server,
and can be all notified at once by means of a single response and can be all notified at once by means of a single response
message. However, CoAP does not currently define response messages message. However, CoAP does not currently define response messages
over IP multicast. This specification fills this gap and provides over IP multicast. This document fills this gap and provides the
the following twofold contribution. following twofold contribution.
First, it updates [RFC7252] and [RFC7641], by defining a method to First, it updates [RFC7252] and [RFC7641], by defining a method to
deliver Observe notifications as CoAP responses addressed to multiple deliver Observe notifications as CoAP responses addressed to multiple
clients, e.g. over IP multicast. In the proposed method, the group clients, e.g., over IP multicast. In the proposed method, the group
of potential observers entrusts the server to manage the Token space of potential observers entrusts the server to manage the Token space
for multicast notifications. By doing so, the server provides all for multicast notifications. By doing so, the server provides all
the observers of a target resource with the same Token value to bind the observers of a target resource with the same Token value to bind
to their own observation. That Token value is then used in every to their own observation. That Token value is then used in every
multicast notification for the target resource. This is achieved by multicast notification for the target resource. This is achieved by
means of an informative unicast response sent by the server to each means of an informative unicast response sent by the server to each
observer client. observer client.
Second, this specification defines how to use Group OSCORE Second, this document defines how to use Group OSCORE
[I-D.ietf-core-oscore-groupcomm] to protect multicast notifications [I-D.ietf-core-oscore-groupcomm] to protect multicast notifications
end-to-end between the server and the observer clients. This is also end-to-end between the server and the observer clients. This is also
achieved by means of the informative unicast response mentioned achieved by means of the informative unicast response mentioned
above, which additionally includes parameter values used by the above, which additionally includes parameter values used by the
server to protect every multicast notification for the target server to protect every multicast notification for the target
resource by using Group OSCORE. This provides a secure binding resource by using Group OSCORE. This provides a secure binding
between each of such notifications and the observation of each of the between each of such notifications and the observation of each of the
clients. clients.
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 18 skipping to change at page 5, line 32
"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 terms and concepts described Readers are expected to be familiar with terms and concepts described
in CoAP [RFC7252], group communication for CoAP in CoAP [RFC7252], group communication for CoAP
[I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949], [I-D.ietf-core-groupcomm-bis], Observe [RFC7641], CBOR [RFC8949],
OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm].
This specification additionally defines the following terminology. This document additionally defines the following terminology.
* Traditional observation. A resource observation associated to a * Traditional observation. A resource observation associated to a
single observer client, as defined in [RFC7641]. single observer client, as defined in [RFC7641].
* Group observation. A resource observation associated to a group * Group observation. A resource observation associated to a group
of clients. The server sends notifications for the group-observed of clients. The server sends notifications for the group-observed
resource over IP multicast to all the observer clients. resource over IP multicast to all the observer clients.
* Phantom request. The CoAP request message that the server would * Phantom request. The CoAP request message that the server would
have received to start or cancel a group observation on one of its have received to start or cancel a group observation on one of its
skipping to change at page 6, line 28 skipping to change at page 6, line 46
notifications. notifications.
2.1. Request 2.1. Request
Assuming it is reachable at the address SRV_ADDR and port number Assuming it is reachable at the address SRV_ADDR and port number
SRV_PORT, the server starts a group observation on one of its SRV_PORT, the server starts a group observation on one of its
resources as defined below. The server intends to send multicast resources as defined below. The server intends to send multicast
notifications for the target resource to the multicast IP address notifications for the target resource to the multicast IP address
GRP_ADDR and port number GRP_PORT. GRP_ADDR and port number GRP_PORT.
1. The server builds a phantom observation request, i.e. a GET 1. The server builds a phantom observation request, i.e., a GET
request with an Observe option set to 0 (register). request with an Observe option set to 0 (register).
2. The server selects an available value T, from the Token space of 2. The server selects an available value T, from the Token space of
a CoAP endpoint used for messages having: a CoAP endpoint used for messages having:
* As source address and port number, the IP multicast address * As source address and port number, the IP multicast address
GRP_ADDR and port number GRP_PORT. GRP_ADDR and port number GRP_PORT.
* As destination address and port number, the server address * As destination address and port number, the server address
SRV_ADDR and port number SRV_PORT, intended for accessing the SRV_ADDR and port number SRV_PORT, intended for accessing the
target resource. target resource.
This Token space is under exclusive control of the server. This Token space is under exclusive control of the server.
3. The server processes the phantom observation request above, 3. The server processes the phantom observation request above,
without transmitting it on the wire. The request is addressed to without transmitting it on the wire. The request is addressed to
the resource for which the server wants to start the group the resource for which the server wants to start the group
observation, as if sent by the group of observers, i.e. with observation, as if sent by the group of observers, i.e., with
GRP_ADDR as source address and GRP_PORT as source port. GRP_ADDR as source address and GRP_PORT as source port.
4. Upon processing the self-generated phantom registration request, 4. Upon processing the self-generated phantom registration request,
the server interprets it as an observe registration received from the server interprets it as an observe registration received from
the group of potential observer clients. In particular, from the group of potential observer clients. In particular, from
then on, the server MUST use T as its own local Token value then on, the server MUST use T as its own local Token value
associated to that observation, with respect to the (previous hop associated to that observation, with respect to the (previous hop
towards the) clients. towards the) clients.
5. The server does not immediately respond to the phantom 5. The server does not immediately respond to the phantom
skipping to change at page 8, line 27 skipping to change at page 8, line 38
* 'last_notif', with value the byte serialization of the transport- * 'last_notif', with value the byte serialization of the transport-
independent information of the latest multicast notification for independent information of the latest multicast notification for
the target resource, encoded as a CBOR byte string. The value of the target resource, encoded as a CBOR byte string. The value of
the CBOR byte string is formatted as defined in Section 2.2.2. the CBOR byte string is formatted as defined in Section 2.2.2.
This parameter MAY be included. This parameter MAY be included.
The CDDL notation [RFC8610] provided below describes the payload of The CDDL notation [RFC8610] provided below describes the payload of
the informative response. the informative response.
informative_response_payload = { informative_response_payload = {
1 => array, ; 'tp_info', i.e. transport-specific information 1 => array, ; 'tp_info', i.e., transport-specific information
2 => bstr, ; 'ph_req' (transport-independent information) 2 => bstr, ; 'ph_req' (transport-independent information)
? 3 => bstr ; 'last_notif' (transport-independent information) ? 3 => bstr ; 'last_notif' (transport-independent information)
} }
Figure 1: Format of the informative response payload Figure 1: Format of the informative response payload
Upon receiving a registration request to observe the target resource, Upon receiving a registration request to observe the target resource,
the server does not create a corresponding individual observation for the server does not create a corresponding individual observation for
the requesting client. Instead, the server considers that client as the requesting client. Instead, the server considers that client as
now taking part in the group observation of the target resource, of now taking part in the group observation of the target resource, of
skipping to change at page 9, line 29 skipping to change at page 9, line 39
) )
Figure 2: General format of 'tp_info' Figure 2: General format of 'tp_info'
The 'srv_addr' element of 'tp_info' specifies the addressing The 'srv_addr' element of 'tp_info' specifies the addressing
information of the server, and includes at least one element 'tp_id' information of the server, and includes at least one element 'tp_id'
which is formatted as follows. which is formatted as follows.
* 'tp_id' : this element is a CBOR integer, which specifies the * 'tp_id' : this element is a CBOR integer, which specifies the
transport protocol used to transport the CoAP response from the transport protocol used to transport the CoAP response from the
server, i.e. a multicast notification in this specification. server, i.e., a multicast notification in this document.
This element takes value from the "Value" column of the "CoAP This element takes value from the "Value" column of the "CoAP
Transport Information" registry defined in Section 14.4 of this Transport Information" registry defined in Section 14.4 of this
specification. This element MUST be present. The value of this document. This element MUST be present. The value of this
element determines: element determines:
- How many elements are required to follow in 'srv_addr', as well - How many elements are required to follow in 'srv_addr', as well
as what information they convey, their encoding and their as what information they convey, their encoding and their
semantics. semantics.
- How many elements are required in the 'req_info' element of the - How many elements are required in the 'req_info' element of the
'tp_info' array, as well as what information they convey, their 'tp_info' array, as well as what information they convey, their
encoding and their semantics. encoding and their semantics.
This specification registers the integer value 1 ("UDP") to be This document registers the integer value 1 ("UDP") to be used as
used as value for the 'tp_id' element, when CoAP responses are value for the 'tp_id' element, when CoAP responses are transported
transported over UDP. In such a case, the full encoding of the over UDP. In such a case, the full encoding of the 'tp_info' CBOR
'tp_info' CBOR array is as defined in Section 2.2.1.1. array is as defined in Section 2.2.1.1.
Future specifications that consider CoAP multicast notifications Future specifications that consider CoAP multicast notifications
transported over different transport protocols MUST: transported over different transport protocols MUST:
- Register an entry with an integer value to be used for 'tp_id', - Register an entry with an integer value to be used for 'tp_id',
in the "CoAP Transport Information" registry defined in in the "CoAP Transport Information" registry defined in
Section 14.4 of this specification. Section 14.4 of this document.
- Accordingly, define the elements of the 'tp_info' CBOR array, - Accordingly, define the elements of the 'tp_info' CBOR array,
i.e. the elements following 'tp_id' in 'srv_addr' as well as i.e., the elements following 'tp_id' in 'srv_addr' as well as
the elements in 'req_info', as to what information they convey, the elements in 'req_info', as to what information they convey,
their encoding and their semantics. their encoding and their semantics.
The 'req_info' element of 'tp_info' specifies transport-specific The 'req_info' element of 'tp_info' specifies transport-specific
information related to a pertinent request message, i.e. the phantom information related to a pertinent request message, i.e., the phantom
observation request in this specification. The exact format of observation request in this document. The exact format of 'req_info'
'req_info' depends on the value of 'tp_id'. depends on the value of 'tp_id'.
Given a specific value of 'tp_id', the complete set of elements Given a specific value of 'tp_id', the complete set of elements
composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is composing 'srv_addr' and 'req_info' in the 'tp_info' CBOR array is
indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP indicated by the two columns "Srv Addr" and "Req Info" of the "CoAP
Transport Information" registry defined in Section 14.4, Transport Information" registry defined in Section 14.4,
respectively. respectively.
2.2.1.1. UDP Transport-Specific Information 2.2.1.1. UDP Transport-Specific Information
When CoAP multicast notifications are transported over UDP as per When CoAP multicast notifications are transported over UDP as per
skipping to change at page 13, line 18 skipping to change at page 13, line 28
2.4. Congestion Control 2.4. Congestion Control
In order to not cause congestion, the server should conservatively In order to not cause congestion, the server should conservatively
control the sending of multicast notifications. In particular: control the sending of multicast notifications. In particular:
* The multicast notifications MUST be Non-confirmable. * The multicast notifications MUST be Non-confirmable.
* In constrained environments such as low-power, lossy networks * In constrained environments such as low-power, lossy networks
(LLNs), the server should only support multicast notifications for (LLNs), the server should only support multicast notifications for
resources that are small. Following related guidelines from resources that are small. Following related guidelines from
Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], this can consist, Section 3.6 of [I-D.ietf-core-groupcomm-bis], this can consist,
for example, in having the payload of multicast notifications as for example, in having the payload of multicast notifications as
limited to approximately 5% of the IP Maximum Transmit Unit (MTU) limited to approximately 5% of the IP Maximum Transmit Unit (MTU)
size, so that it fits into a single link-layer frame in case IPv6 size, so that it fits into a single link-layer frame in case IPv6
over Low-Power Wireless Personal Area Networks (6LoWPAN) (see over Low-Power Wireless Personal Area Networks (6LoWPAN) (see
Section 4 of [RFC4944]) is used. Section 4 of [RFC4944]) is used.
* The server SHOULD provide multicast notifications with the * The server SHOULD provide multicast notifications with the
smallest possible IP multicast scope that fulfills the application smallest possible IP multicast scope that fulfills the application
needs. For example, following related guidelines from needs. For example, following related guidelines from Section 3.6
Section 2.2.4 of [I-D.ietf-core-groupcomm-bis], site-local scope of [I-D.ietf-core-groupcomm-bis], site-local scope is always
is always preferred over global scope IP multicast, if this preferred over global scope IP multicast, if this fulfills the
fulfills the application needs. Similarly, realm-local scope is application needs. Similarly, realm-local scope is always
always preferred over site-local scope, if this fulfills the preferred over site-local scope, if this fulfills the application
application needs. needs.
* Following related guidelines from Section 4.5.1 of [RFC7641], the * Following related guidelines from Section 4.5.1 of [RFC7641], the
server SHOULD NOT send more than one multicast notification every server SHOULD NOT send more than one multicast notification every
3 seconds, and SHOULD use an even less aggressive rate when 3 seconds, and SHOULD use an even less aggressive rate when
possible (see also Section 3.1.2 of [RFC8085]). The transmission possible (see also Section 3.1.2 of [RFC8085]). The transmission
rate of multicast notifications should also take into account the rate of multicast notifications should also take into account the
avoidance of a possible "broadcast storm" problem [MOBICOM99]. avoidance of a possible "broadcast storm" problem [MOBICOM99].
This prevents a following, considerable increase of the channel This prevents a following, considerable increase of the channel
load, whose origin would be likely attributed to a router rather load, whose origin would be likely attributed to a router rather
than the server. than the server.
2.5. Cancellation 2.5. Cancellation
At any point in time, the server may want to cancel a group At any point in time, the server may want to cancel a group
observation of a target resource. For instance, the server may observation of a target resource. For instance, the server may
realize that no clients or not enough clients are interested in realize that no clients or not enough clients are interested in
taking part in the group observation anymore. A possible approach taking part in the group observation anymore. A possible approach
that the server can use to assess this is defined in Section 6. that the server can use to assess this is defined in Section 6.
In order to cancel the group observation, the server sends to itself In order to cancel the group observation, the server sends a
a phantom cancellation request, i.e. a GET request with an Observe multicast response with response code 5.03 (Service Unavailable),
option set to 1 (deregister), without transmitting it on the wire. signaling that the group observation has been terminated. The
As per Section 3.6 of [RFC7641], all other options MUST be identical response has the same Token value T of the phantom registration
to those in the phantom registration request, except for the set of request, it has no payload, and it does not include an Observe
ETag Options. This request has the same Token value T of the phantom option.
registration request, and is addressed to the resource for which the
server wants to end the group observation, as if sent by the group of
observers, i.e. with the multicast IP address GRP_ADDR as source
address and the port number GRP_PORT as source port.
After that, the server sends a multicast response with response code The server sends the response to the same multicast IP address
5.03 (Service Unavailable), signaling that the group observation has GRP_ADDR and port number GRP_PORT used to send the multicast
been terminated. The response has no payload, and is sent to the notifications related to the target resource. Finally, the server
same multicast IP address GRP_ADDR and port number GRP_PORT used to releases the resources allocated for the group observation, and
send the multicast notifications related to the target resource. As especially frees up the Token value T used at its CoAP endpoint.
per [RFC7641], this response does not include an Observe option.
Finally, the server releases the resources allocated for the group
observation, and especially frees up the Token value T used at its
CoAP endpoint.
3. Client-Side Requirements 3. Client-Side Requirements
3.1. Request 3.1. Request
A client sends an observation request to the server as described in A client sends an observation request to the server as described in
[RFC7641], i.e. a GET request with an Observe option set to 0 [RFC7641], i.e., a GET request with an Observe option set to 0
(register). The request MUST NOT encode link-local addresses. If (register). The request MUST NOT encode link-local addresses. If
the server is not configured to accept registrations on that target the server is not configured to accept registrations on that target
resource with a group observation, this would still result in a resource with a group observation, this would still result in a
positive notification response to the client as described in positive notification response to the client as described in
[RFC7641]. [RFC7641].
3.2. Informative Response 3.2. Informative Response
Upon receiving the informative response defined in Section 2.2, the Upon receiving the informative response defined in Section 2.2, the
client proceeds as follows. client proceeds as follows.
skipping to change at page 16, line 43 skipping to change at page 16, line 51
In case the server has canceled a group observation as defined in In case the server has canceled a group observation as defined in
Section 2.5, the client simply forgets about the group observation Section 2.5, the client simply forgets about the group observation
and frees up the used Token value T for that endpoint, upon receiving and frees up the used Token value T for that endpoint, upon receiving
the multicast error response defined in Section 2.5. the multicast error response defined in Section 2.5.
4. Web Linking 4. Web Linking
The possible use of multicast notifications in a group observation The possible use of multicast notifications in a group observation
may be indicated by a target "grp_obs" attribute in a web link may be indicated by a target "grp_obs" attribute in a web link
[RFC8288] to a resource, e.g. using a link-format document [RFC6690] [RFC8288] to a resource, e.g., using a link-format document
if the resource is accessible over CoAP. [RFC6690].
The "grp_obs" attribute is a hint, indicating that the server might The "grp_obs" attribute is a hint, indicating that the server might
send multicast notifications for observations of the resource send multicast notifications for observations of the resource
targeted by the link. Note that this is simply a hint, i.e. it does targeted by the link. Note that this is simply a hint, i.e., it does
not include any information required to participate in a group not include any information required to participate in a group
observation, and to receive and process multicast notifications. observation, and to receive and process multicast notifications.
A value MUST NOT be given for the "grp_obs" attribute; any present A value MUST NOT be given for the "grp_obs" attribute; any present
value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT value MUST be ignored by parsers. The "grp_obs" attribute MUST NOT
appear more than once in a given link-value; occurrences after the appear more than once in a given link-value; occurrences after the
first MUST be ignored by parsers. first MUST be ignored by parsers.
The example in Figure 4 shows a use of the "grp_obs" attribute: the The example in Figure 4 shows a use of the "grp_obs" attribute: the
client does resource discovery on a server and gets back a list of client does resource discovery on a server and gets back a list of
skipping to change at page 18, line 34 skipping to change at page 18, line 42
| | | |
| (S creates a group observation of /r .) | | (S creates a group observation of /r .) |
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
C_1 <-------------------- [ Unicast ] --------------------- S C_1 <-------------------- [ Unicast ] --------------------- S
| 5.03 | | 5.03 |
| Token: 0x4a | | Token: 0x4a |
| Content-Format: application/informative-response+cbor | | Content-Format: application/informative-response+cbor |
| Max-Age: 0 |
| <Other options> | | <Other options> |
| Payload: { | | Payload: { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x01 | OPT), | | ph_req : bstr(0x01 | OPT), |
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) |
| } | | } |
| | | |
| |
| |
C_2 ----------------- [ Unicast ] ------------------------> S /r C_2 ----------------- [ Unicast ] ------------------------> S /r
| GET | | GET |
| Token: 0x01 | | Token: 0x01 |
| Observe: 0 (Register) | | Observe: 0 (Register) |
| <Other options> | | <Other options> |
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
| | | |
C_2 <-------------------- [ Unicast ] --------------------- S C_2 <-------------------- [ Unicast ] --------------------- S
| 5.03 | | 5.03 |
| Token: 0x01 | | Token: 0x01 |
| Content-Format: application/informative-response+cbor | | Content-Format: application/informative-response+cbor |
| Max-Age: 0 |
| <Other options> | | <Other options> |
| Payload: { | | Payload: { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x01 | OPT), | | ph_req : bstr(0x01 | OPT), |
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD) |
| } | | } |
| | | |
| (The value of the resource /r changes to "5678".) | | (The value of the resource /r changes to "5678".) |
| | | |
| |
C_1 | C_1 |
+ <------------------- [ Multicast ] -------------------- S + <------------------- [ Multicast ] -------------------- S
C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | C_2 (Destination address/port: GRP_ADDR/GRP_PORT) |
| 2.05 | | 2.05 |
| Token: 0x7b | | Token: 0x7b |
| Observe: 11 | | Observe: 11 |
| Content-Format: application/cbor | | Content-Format: application/cbor |
| <Other options> | | <Other options> |
| Payload: : "5678" | | Payload: : "5678" |
| | | |
Figure 5: Example of group observation Figure 5: Example of group observation
6. Rough Counting of Clients in the Group Observation 6. Rough Counting of Clients in the Group Observation
To allow the server to keep an estimate of interested clients without 6.1. Multicast-Response-Feedback-Divider Option
creating undue traffic on the network, a new CoAP option is
introduced, which SHOULD be supported by clients that listen to In order to allow the server to keep an estimate of interested
multicast responses. clients without creating undue traffic on the network, a new CoAP
option is introduced, which SHOULD be supported by clients that
listen to multicast responses.
The option is called Multicast-Response-Feedback-Divider. As The option is called Multicast-Response-Feedback-Divider. As
summarized in Figure 6, the option is not critical but proxy-unsafe, summarized in Figure 6, the option is not Critical, not Safe-to-
and integer valued. Forward, and integer valued. Since the option is not Safe-to-
Forward, the column "N" indicates a dash for "not applicable".
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | | No. | C | U | N | R | Name | Format | Len. | Default |
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
| TBD | | x | | | Multicast-Response- | uint | 0-1 | (none) | | TBD | | x | - | | Multicast-Response- | uint | 0-1 | (none) |
| | | | | | Feedback-Divider | | | | | | | | | | Feedback-Divider | | | |
+-----+---+---+---+---+---------------------+--------+------+---------+ +-----+---+---+---+---+---------------------+--------+------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
Figure 6: Multicast-Response-Feedback-Divider Figure 6: Multicast-Response-Feedback-Divider
The Multicast-Response-Feedback-Divider option is of class E for The Multicast-Response-Feedback-Divider option is of class E for
OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm]. OSCORE [RFC8613][I-D.ietf-core-oscore-groupcomm].
6.1. Processing on the Client Side 6.2. Processing on the Client Side
Upon receiving a response with a Multicast-Response-Feedback-Divider Upon receiving a response with a Multicast-Response-Feedback-Divider
option, a client SHOULD acknowledge its interest in continuing option, a client SHOULD acknowledge its interest in continuing
receiving multicast notifications for the target resource, as receiving multicast notifications for the target resource, as
described below. described below.
The client picks an integer random number I, from 0 inclusive to the The client picks an integer random number I, from 0 inclusive to the
number Z = (2 ** Q) exclusive, where Q is the value specified in the number Z = (2 ** Q) exclusive, where Q is the value specified in the
option and "**" is the exponentiation operator. If I is different option and "**" is the exponentiation operator. If I is different
than 0, the client takes no further action. Otherwise, the client than 0, the client takes no further action. Otherwise, the client
should wait a random fraction of the Leisure time (see Section 8.2 of should wait a random fraction of the Leisure time (see Section 8.2 of
[RFC7252]), and then registers a regular unicast observation on the [RFC7252]), and then registers a regular unicast observation on the
same target resource. same target resource.
To this end, the client essentially follows the steps that got it To this end, the client essentially follows the steps that got it
originally subscribed to group notifications for the target resource. originally subscribed to group notifications for the target resource.
In particular, the client sends an observation request to the server, In particular, the client sends an observation request to the server,
i.e. a GET request with an Observe option set to 0 (register). The i.e., a GET request with an Observe option set to 0 (register). The
request MUST be addressed to the same target resource, and MUST have request MUST be addressed to the same target resource, and MUST have
the same destination IP address and port number used for the original the same destination IP address and port number used for the original
registration request, regardless the source IP address and port registration request, regardless the source IP address and port
number of the received multicast notification. number of the received multicast notification.
Since the observation registration is only done for its side effect Since the observation registration is only done for its side effect
of showing as an attempted observation at the server, the client MUST of showing as an attempted observation at the server, the client MUST
send the unicast request in a non confirmable way, and with the send the unicast request in a non confirmable way, and with the
maximum No-Response setting [RFC7967]. In the request, the client maximum No-Response setting [RFC7967]. In the request, the client
MUST include a Multicast-Response-Feedback-Divider option, whose MUST include a Multicast-Response-Feedback-Divider option, whose
value MUST be empty (Option Length = 0). The client does not need to value MUST be empty (Option Length = 0). The client does not need to
wait for responses, and can keep processing further notifications on wait for responses, and can keep processing further notifications on
the same token. the same Token.
The client MUST ignore the Multicast-Response-Feedback-Divider The client MUST ignore the Multicast-Response-Feedback-Divider
option, if the multicast notification is retrieved from the option, if the multicast notification is retrieved from the
'last_notif' parameter of an informative response (see Section 2.2). 'last_notif' parameter of an informative response (see Section 2.2).
A client includes the Multicast-Response-Feedback-Divider option only A client includes the Multicast-Response-Feedback-Divider option only
in a re-registration request triggered by the server as described in a re-registration request triggered by the server as described
above, and MUST NOT include it in any other request. above, and MUST NOT include it in any other request.
As the Multicast-Response-Feedback-Divider option is unsafe to As the Multicast-Response-Feedback-Divider option is unsafe to
forward, a proxy needs to answer it on its own, and is later counted forward, a proxy needs to answer it on its own, and is later counted
as a single client. as a single client.
Appendix B.1 provides a description in pseudo-code of the operations Appendix B.1 and Appendix B.2 provide a description in pseudo-code of
above performed by the client. the operations above performed by the client.
6.2. Processing on the Server Side 6.3. Processing on the Server Side
In order to avoid needless use of network resources, a server SHOULD In order to avoid needless use of network resources, a server SHOULD
keep a rough, updated count of the number of clients taking part in keep a rough, updated count of the number of clients taking part in
the group observation of a target resource. To this end, the server the group observation of a target resource. To this end, the server
updates the value COUNT of the associated observer counter (see updates the value COUNT of the associated observer counter (see
Section 2), for instance by using the method described below. Section 2), for instance by using the method described below.
6.2.1. Request for Feedback 6.3.1. Request for Feedback
When it wants to obtain a new estimated count, the server considers a When it wants to obtain a new estimated count, the server considers a
number M of confirmations it would like to receive from the clients. number M of confirmations it would like to receive from the clients.
It is up to applications to define policies about how the server It is up to applications to define policies about how the server
determines and possibly adjusts the value of M. determines and possibly adjusts the value of M.
Then, the server computes the value Q = max(L, 0), where: Then, the server computes the value Q = max(L, 0), where:
* L is computed as L = ceil(log2(N / M)). * L is computed as L = ceil(log2(N / M)).
* N is the current value of the observer counter, possibly rounded * N is the current value of the observer counter, possibly rounded
up to 1, i.e. N = max(COUNT, 1). up to 1, i.e., N = max(COUNT, 1).
Finally, the server sets Q as the value of the Multicast-Response- Finally, the server sets Q as the value of the Multicast-Response-
Feedback-Divider option, which is sent within a successful multicast Feedback-Divider option, which is sent within a successful multicast
notification. notification.
If several multicast notifications are sent in a burst fashion, it is If several multicast notifications are sent in a burst fashion, it is
RECOMMENDED for the server to include the Multicast-Response- RECOMMENDED for the server to include the Multicast-Response-
Feedback-Divider option only in the first one of those notifications. Feedback-Divider option only in the first one of those notifications.
6.2.2. Collection of Feedback 6.3.2. Collection of Feedback
The server collects unicast observation requests from the clients, The server collects unicast observation requests from the clients,
for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this for an amount of time of MAX_CONFIRMATION_WAIT seconds. During this
time, the server regularly increments the observer counter when time, the server regularly increments the observer counter when
adding a new client to the group observation (see Section 2.2). adding a new client to the group observation (see Section 2.2).
It is up to applications to define the value of It is up to applications to define the value of
MAX_CONFIRMATION_WAIT, which has to take into account the MAX_CONFIRMATION_WAIT, which has to take into account the
transmission time of the multicast notification and of unicast transmission time of the multicast notification and of unicast
observation requests, as well as the leisure time of the clients, observation requests, as well as the leisure time of the clients,
which may be hard to know or estimate for the server. which may be hard to know or estimate for the server.
If this information is not known to the server, it is recommended to If this information is not known to the server, it is recommended to
define MAX_CONFIRMATION_WAIT as follows. define MAX_CONFIRMATION_WAIT as follows.
MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY MAX_CONFIRMATION_WAIT = MAX_RTT + MAX_CLIENT_REQUEST_DELAY
where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has where MAX_RTT is as defined in Section 4.8.2 of [RFC7252] and has
default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is default value 202 seconds, while MAX_CLIENT_REQUEST_DELAY is
equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 2.3.1 of equivalent to MAX_SERVER_RESPONSE_DELAY defined in Section 3.1.5 of
[I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In [I-D.ietf-core-groupcomm-bis] and has default value 250 seconds. In
the absence of more specific information, the server can thus the absence of more specific information, the server can thus
consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds. consider a conservative MAX_CONFIRMATION_WAIT of 452 seconds.
If more information is available in deployments, a much shorter If more information is available in deployments, a much shorter
MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic MAX_CONFIRMATION_WAIT can be set. This can be based on a realistic
round trip time (replacing MAX_RTT) and on the largest leisure time round trip time (replacing MAX_RTT) and on the largest leisure time
configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g. configured on the clients (replacing MAX_CLIENT_REQUEST_DELAY), e.g.,
DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to DEFAULT_LEISURE = 5 seconds, thus shortening MAX_CONFIRMATION_WAIT to
a few seconds. a few seconds.
6.2.3. Processing of Feedback 6.3.3. Processing of Feedback
Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the Once MAX_CONFIRMATION_WAIT seconds have passed, the server counts the
R confirmations arrived as unicast observation requests to the target R confirmations arrived as unicast observation requests to the target
resource, since the multicast notification with the Multicast- resource, since the multicast notification with the Multicast-
Response-Feedback-Divider option has been sent. In particular, the Response-Feedback-Divider option has been sent. In particular, the
server considers a unicast observation request as a confirmation from server considers a unicast observation request as a confirmation from
a client only if it includes a Multicast-Response-Feedback-Divider a client only if it includes a Multicast-Response-Feedback-Divider
option with an empty value (Option Length = 0). option with an empty value (Option Length = 0).
Then, the server computes a feedback indicator as E = R * (2 ** Q), Then, the server computes a feedback indicator as E = R * (2 ** Q),
where "**" is the exponentiation operator. According to what defined where "**" is the exponentiation operator. According to what defined
by application policies, the server determines the next time when to by application policies, the server determines the next time when to
ask clients for their confirmation, e.g. after a certain number of ask clients for their confirmation, e.g., after a certain number of
multicast notifications has been sent. For example, the decision can multicast notifications has been sent. For example, the decision can
be influenced by the reception of no confirmations from the clients, be influenced by the reception of no confirmations from the clients,
i.e. R = 0, or by the value of the ratios (E/N) and (N/E). i.e., R = 0, or by the value of the ratios (E/N) and (N/E).
Finally, the server computes a new estimated count of the observers. Finally, the server computes a new estimated count of the observers.
To this end the server first consider COUNT' as the current value of To this end, the server first consider COUNT' as the current value of
the observer counter at this point in time. Note that COUNT' may be the observer counter at this point in time. Note that COUNT' may be
greater than the value COUNT used at the beginning of this process, greater than the value COUNT used at the beginning of this process,
if the server has incremented the observer counter upon adding new if the server has incremented the observer counter upon adding new
clients to the group observation (see Section 2.2). clients to the group observation (see Section 2.2).
In particular, the server computes the new estimated count value as In particular, the server computes the new estimated count value as
COUNT' + ((E - N) / D), where D > 0 is an integer value used as COUNT' + ((E - N) / D), where D > 0 is an integer value used as
dampener. This step has to be performed atomically. That is, until dampener. This step has to be performed atomically. That is, until
this step is completed, the server MUST hold the processing of an this step is completed, the server MUST hold the processing of an
observation request for the same target resource from a new client. observation request for the same target resource from a new client.
skipping to change at page 23, line 27 skipping to change at page 23, line 42
policies about how the server takes the newly updated estimate into policies about how the server takes the newly updated estimate into
account and determines whether to cancel the group observation. account and determines whether to cancel the group observation.
As an example, if the server currently estimates that N = COUNT = 32 As an example, if the server currently estimates that N = COUNT = 32
observers are active and considers a constant M = 8, it sends out a observers are active and considers a constant M = 8, it sends out a
notification with Multicast-Response-Feedback-Divider: 2. Then, out notification with Multicast-Response-Feedback-Divider: 2. Then, out
of 18 actually active clients, 5 send a re-registration request based of 18 actually active clients, 5 send a re-registration request based
on their random draw, of which one request gets lost, thus leaving 4 on their random draw, of which one request gets lost, thus leaving 4
re-registration requests received by the server. Also, no new re-registration requests received by the server. Also, no new
clients have been added to the group observation during this time, clients have been added to the group observation during this time,
i.e. COUNT' is equal to COUNT. As a consequence, assuming that a i.e., COUNT' is equal to COUNT. As a consequence, assuming that a
dampener value D = 1 is used, the server computes the new estimated dampener value D = 1 is used, the server computes the new estimated
count value as 32 + (16 - 32) = 16, and keeps the group observation count value as 32 + (16 - 32) = 16, and keeps the group observation
active. active.
To produce a most accurate updated counter, a server can include a To produce a most accurate updated counter, a server can include a
Multicast-Response-Feedback-Divider option with value Q = 0 in its Multicast-Response-Feedback-Divider option with value Q = 0 in its
multicast notifications, as if M is equal to N. This will trigger multicast notifications, as if M is equal to N. This will trigger
all the active clients to state their interest in continuing all the active clients to state their interest in continuing
receiving notifications for the target resource. Thus, the amount R receiving notifications for the target resource. Thus, the amount R
of arrived confirmations is affected only by possible packet loss. of arrived confirmations is affected only by possible packet loss.
skipping to change at page 24, line 15 skipping to change at page 24, line 28
In some settings, the OSCORE group to refer to can be pre-configured In some settings, the OSCORE group to refer to can be pre-configured
on the clients and the server. In such a case, a server which is on the clients and the server. In such a case, a server which is
aware of such pre-configuration can simply assume a client to be aware of such pre-configuration can simply assume a client to be
already member of the correct OSCORE group. already member of the correct OSCORE group.
In any other case, the server MAY communicate to clients what OSCORE In any other case, the server MAY communicate to clients what OSCORE
group they are required to join, by providing additional guidance in group they are required to join, by providing additional guidance in
the informative response as described in Section 7.1. Note that the informative response as described in Section 7.1. Note that
clients can already be members of the right OSCORE group, in case clients can already be members of the right OSCORE group, in case
they have previously joined it to securely communicate with the same they have previously joined it to securely communicate with the same
and/or other servers to access their resources. server and/or with other servers to access their resources.
Both the clients and the server MAY join the OSCORE group by using Both the clients and the server MAY join the OSCORE group by using
the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and the approach described in [I-D.ietf-ace-key-groupcomm-oscore] and
based on the ACE framework for Authentication and Authorization in based on the ACE framework for Authentication and Authorization in
constrained environments [I-D.ietf-ace-oauth-authz]. Further details constrained environments [I-D.ietf-ace-oauth-authz]. Further details
on how to discover the OSCORE group and join it are out of the scope on how to discover the OSCORE group and join it are out of the scope
of this specification. of this document.
If multicast notifications are protected using Group OSCORE, the If multicast notifications are protected using Group OSCORE, the
original registration requests and related unicast (notification) original registration requests and related unicast (notification)
responses MUST also be secured, including and especially the responses MUST also be secured, including and especially the
informative responses from the server. informative responses from the server.
To this end, alternative security protocols than Group OSCORE, such To this end, alternative security protocols than Group OSCORE, such
as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can as OSCORE [RFC8613] and/or DTLS [RFC6347][I-D.ietf-tls-dtls13], can
be used to protect other exchanges via unicast between the server and be used to protect other exchanges via unicast between the server and
each client, including the original client registration (see each client, including the original client registration (see
Section 3). Section 3).
7.1. Signaling the OSCORE Group in the Informative Response 7.1. Signaling the OSCORE Group in the Informative Response
This section describes a mechanism for the server to communicate to This section describes a mechanism for the server to communicate to
the client what OSCORE group to join in order to decrypt and verify the client what OSCORE group to join in order to decrypt and verify
the multicast notifications protected with group OSCORE. The client the multicast notifications protected with Group OSCORE. The client
MAY use the information provided by the server to start the ACE MAY use the information provided by the server to start the ACE
joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore]. joining procedure described in [I-D.ietf-ace-key-groupcomm-oscore].
This mechanism is OPTIONAL to support for the client and server. This mechanism is OPTIONAL to support for the client and server.
Additionally to what defined in Section 2, the CBOR map in the Additionally to what defined in Section 2, the CBOR map in the
informative response payload contains the following fields, whose informative response payload contains the following fields, whose
CBOR labels are defined in Section 11. CBOR labels are defined in Section 11.
* 'join_uri', with value the URI for joining the OSCORE group at the * 'join_uri', with value the URI for joining the OSCORE group at the
respective Group Manager, encoded as a CBOR text string. If the respective Group Manager, encoded as a CBOR text string. If the
skipping to change at page 25, line 12 skipping to change at page 25, line 31
for joining, this field specifically indicates the URI of the for joining, this field specifically indicates the URI of the
group-membership resource at the Group Manager. group-membership resource at the Group Manager.
* 'sec_gp', with value the name of the OSCORE group, encoded as a * 'sec_gp', with value the name of the OSCORE group, encoded as a
CBOR text string. CBOR text string.
* Optionally, 'as_uri', with value the URI of the Authorization * Optionally, 'as_uri', with value the URI of the Authorization
Server associated to the Group Manager for the OSCORE group, Server associated to the Group Manager for the OSCORE group,
encoded as a CBOR text string. encoded as a CBOR text string.
* Optionally, 'cs_alg', with value the COSE algorithm * Optionally, 'hkdf', with value the HKDF Algorithm used in the
[I-D.ietf-cose-rfc8152bis-algs] used to countersign messages in OSCORE group, encoded as a CBOR text string or integer. The value
the OSCORE group, encoded as a CBOR text string or integer. The is taken from the 'Value' column of the "COSE Algorithms" registry
value is taken from the 'Value' column of the "COSE Algorithms" [COSE.Algorithms].
registry [COSE.Algorithms].
* Optionally, 'cs_alg_crv', with value the elliptic curve (if * Optionally, 'pub_key_enc', with value the encoding of the public
applicable) for the COSE algorithm [I-D.ietf-cose-rfc8152bis-algs] keys used in the OSCORE group, encoded as a CBOR integer. The
used to countersign messages in the OSCORE group, encoded as a value is taken from the 'Label' column of the "COSE Header
CBOR text string or integer. The value is taken from the 'Value' Parameters" Registry [COSE.Header.Parameters]. Consistently with
column of the "COSE Elliptic Curve" registry Section 2.3 of [I-D.ietf-core-oscore-groupcomm], acceptable values
[COSE.Elliptic.Curves]. denote an encoding that MUST explicitly provide the full set of
information related to the public key algorithm, including, e.g.,
the used elliptic curve (when applicable).
* Optionally, 'cs_key_kty', with value the COSE key type At the time of writing this specification, acceptable public key
[I-D.ietf-cose-rfc8152bis-struct] of countersignature keys used to encodings are CWTs [RFC8392], unprotected CWT claim sets
countersign messages in the OSCORE group, encoded as a CBOR text [I-D.ietf-rats-uccs], X.509 certificates [RFC7925] and C509
string or an integer. The value is taken from the 'Value' column certificates [I-D.ietf-cose-cbor-encoded-cert]. Further encodings
of the "COSE Key Types" registry [COSE.Key.Types]. may be available in the future, and would be acceptable to use as
long as they comply with the criteria defined above.
* Optionally, 'cs_key_crv', with value the elliptic curve (if [ As to CWTs and unprotected CWT claim sets, there is a pending
applicable) of countersignature keys used to countersign messages registration requested by draft-ietf-lake-edhoc. ]
in the OSCORE group, encoded as a CBOR text string or integer.
The value is taken from the 'Value' column of the "COSE Elliptic
Curve" registry [COSE.Elliptic.Curves].
* Optionally, 'cs_kenc', with value the encoding of the public keys [ As to C509 certificates, there is a pending registration
used in the OSCORE group, encoded as a CBOR integer. The value is requested by draft-ietf-cose-cbor-encoded-cert. ]
taken from the 'Confirmation Key' column of the "CWT Confirmation
Method" registry defined in [RFC8747]. Future specifications may
define additional values for this parameter.
* Optionally, 'alg', with value the COSE AEAD algorithm * Optionally, 'sign_enc_alg', with value the Signature Encryption
[I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or Algorithm used in the OSCORE group to encrypt messages protected
integer. The value is taken from the 'Value' column of the "COSE with the group mode, encoded as a CBOR text string or integer.
The value is taken from the 'Value' column of the "COSE
Algorithms" registry [COSE.Algorithms]. Algorithms" registry [COSE.Algorithms].
* Optionally, 'hkdf', with value the COSE HKDF algorithm * Optionally, 'sign_alg', with value the Signature Algorithm used to
[I-D.ietf-cose-rfc8152bis-algs], encoded as a CBOR text string or sign messages in the OSCORE group, encoded as a CBOR text string
integer. The value is taken from the 'Value' column of the "COSE or integer. The value is taken from the 'Value' column of the
Algorithms" registry [COSE.Algorithms]. "COSE Algorithms" registry [COSE.Algorithms].
The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv' and * Optionally, 'sign_params', encoded as a CBOR array and including
'cs_key_kenc' provide an early knowledge of the format and encoding the following two elements:
of public keys used in the OSCORE group. Thus, the client does not
need to ask the Group Manager for this information as a preliminary
step before the (ACE) join process, or to perform a trial-and-error
exchange with the Group Manager upon joining the group. Hence, the
client is able to provide the Group Manager with its own public key
in the correct expected format and encoding, at the very first step
of the (ACE) join process.
The values of 'cs_alg', 'alg' and 'hkdf' provide an early knowledge - 'sign_alg_capab': a CBOR array, with the same format and value
of the algorithms used in the OSCORE group. Thus, the client is able of the COSE capabilities array for the algorithm indicated in
to decide whether to actually proceed with the (ACE) join process, 'sign_alg', as specified for that algorithm in the
depending on its support for the indicated algorithms. 'Capabilities' column of the "COSE Algorithms" Registry
[COSE.Algorithms].
- 'sign_key_type_capab': a CBOR array, with the same format and
value of the COSE capabilities array for the COSE key type of
the keys used with the algorithm indicated in 'sign_alg', as
specified for that key type in the 'Capabilities' column of the
"COSE Key Types" Registry [COSE.Key.Types].
The values of 'sign_alg', 'sign_params' and 'pub_key_enc' provide an
early knowledge of the format and encoding of public keys used in the
OSCORE group. Thus, the client does not need to ask the Group
Manager for this information as a preliminary step before the (ACE)
join process, or to perform a trial-and-error exchange with the Group
Manager upon joining the group. Hence, the client is able to provide
the Group Manager with its own public key in the correct expected
format and encoding, at the very first step of the (ACE) join
process.
The values of 'hkdf', 'sign_enc_alg' and 'sign_alg' provide an early
knowledge of the algorithms used in the OSCORE group. Thus, the
client is able to decide whether to actually proceed with the (ACE)
join process, depending on its support for the indicated algorithms.
As mentioned above, since this mechanism is OPTIONAL, all the fields As mentioned above, since this mechanism is OPTIONAL, all the fields
are OPTIONAL in the informative response. However, the 'join_uri' are OPTIONAL in the informative response. However, the 'join_uri'
and 'sec_gp' fields MUST be present if the mechanism is implemented and 'sec_gp' fields MUST be present if the mechanism is implemented
and used. If any of the fields are present without the 'join_uri' and used. If any of the fields are present without the 'join_uri'
and 'sec_gp' fields present, the client MUST ignore these fields, and 'sec_gp' fields present, the client MUST ignore these fields,
since they would not be sufficient to start the (ACE) join procedure. since they would not be sufficient to start the (ACE) join procedure.
When this happens, the client MAY try sending a new registration When this happens, the client MAY try sending a new registration
request to the server (see Section 3.1). Otherwise, the client request to the server (see Section 3.1). Otherwise, the client
SHOULD explicitly withdraw from the group observation. SHOULD explicitly withdraw from the group observation.
skipping to change at page 26, line 51 skipping to change at page 27, line 36
following differences. following differences.
7.2.1. Registration 7.2.1. Registration
The phantom registration request MUST be secured, by using Group The phantom registration request MUST be secured, by using Group
OSCORE. In particular, the group mode of Group OSCORE defined in OSCORE. In particular, the group mode of Group OSCORE defined in
Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used. Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST be used.
The server protects the phantom registration request as defined in The server protects the phantom registration request as defined in
Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the Section 8.1 of [I-D.ietf-core-oscore-groupcomm], as if it was the
actual sender, i.e. by using its Sender Context. As a consequence, actual sender, i.e., by using its Sender Context. As a consequence,
the server consumes the current value of its Sender Sequence Number the server consumes the current value of its Sender Sequence Number
SN in the OSCORE group, and hence updates it to SN* = (SN + 1). SN in the OSCORE group, and hence updates it to SN* = (SN + 1).
Consistently, the OSCORE option in the phantom registration request Consistently, the OSCORE option in the phantom registration request
includes: includes:
* As 'kid', the Sender ID of the server in the OSCORE group. * As 'kid', the Sender ID of the server in the OSCORE group.
* As 'piv', the previously consumed Sender Sequence Number value SN * As 'piv', the previously consumed Sender Sequence Number value SN
of the server in the OSCORE group, i.e. (SN* - 1). of the server in the OSCORE group, i.e., (SN* - 1).
7.2.2. Informative Response 7.2.2. Informative Response
The value of the CBOR byte string in the 'ph_req' parameter encodes The value of the CBOR byte string in the 'ph_req' parameter encodes
the phantom observation request as a message protected with Group the phantom observation request as a message protected with Group
OSCORE (see Section 7.2.1). As a consequence: the specified Code is OSCORE (see Section 7.2.1). As a consequence: the specified Code is
always 0.05 (FETCH); the sequence of CoAP options will be limited to always 0.05 (FETCH); the sequence of CoAP options will be limited to
the outer, non encrypted options; a payload is always present, as the the outer, non encrypted options; a payload is always present, as the
authenticated ciphertext followed by the counter signature. authenticated ciphertext followed by the signature.
Similarly, the value of the CBOR byte string in the 'last_notif' Similarly, the value of the CBOR byte string in the 'last_notif'
parameter encodes the latest multicast notification as a message parameter encodes the latest multicast notification as a message
protected with Group OSCORE (see Section 7.2.3). This applies also protected with Group OSCORE (see Section 7.2.3). This applies also
to the initial multicast notification INIT_NOTIF built in step 6 of to the initial multicast notification INIT_NOTIF built in step 6 of
Section 2.1. Section 2.1.
Optionally, the informative response includes information on the Optionally, the informative response includes information on the
OSCORE group to join, as additional parameters (see Section 7.1). OSCORE group to join, as additional parameters (see Section 7.1).
7.2.3. Notifications 7.2.3. Notifications
The server MUST protect every multicast notification for the target The server MUST protect every multicast notification for the target
resource with Group OSCORE. In particular, the group mode of Group resource with Group OSCORE. In particular, the group mode of Group
OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST OSCORE defined in Section 8 of [I-D.ietf-core-oscore-groupcomm] MUST
be used. be used.
The process described in Section 8.3 of The process described in Section 8.3 of
[I-D.ietf-core-oscore-groupcomm] applies, with the following [I-D.ietf-core-oscore-groupcomm] applies, with the following
additions when building the two OSCORE 'external_aad' to encrypt and additions when building the two OSCORE 'external_aad' to encrypt and
countersign the multicast notification (see Sections 4.3.1 and 4.3.2 sign the multicast notification (see Section 4.3 of
of [I-D.ietf-core-oscore-groupcomm]). [I-D.ietf-core-oscore-groupcomm]).
* The 'request_kid' is the 'kid' value in the OSCORE option of the * The 'request_kid' is the 'kid' value in the OSCORE option of the
phantom registration request, i.e. the Sender ID of the server. phantom registration request, i.e., the Sender ID of the server.
* The 'request_piv' is the 'piv' value in the OSCORE option of the * The 'request_piv' is the 'piv' value in the OSCORE option of the
phantom registration request, i.e. the consumed Sender Sequence phantom registration request, i.e., the consumed Sender Sequence
Number SN of the server. Number SN of the server.
* The 'request_kid_context' is the 'kid context' value in the OSCORE * The 'request_kid_context' is the 'kid context' value in the OSCORE
option of the phantom registration request, i.e. the Group option of the phantom registration request, i.e., the Group
Identifier value (Gid) of the OSCORE group used as ID Context. Identifier value (Gid) of the OSCORE group used as ID Context.
Note that these same values are used to protect each and every Note that these same values are used to protect each and every
multicast notification sent for the target resource under this group multicast notification sent for the target resource under this group
observation. observation.
7.2.4. Cancellation 7.2.4. Cancellation
When canceling a group observation (see Section 2.5), the phantom When canceling a group observation (see Section 2.5), the multicast
cancellation request MUST be secured, by using Group OSCORE. In response with error code 5.03 (Service Unavailable) is also protected
particular, the group mode of Group OSCORE defined in Section 8 of
[I-D.ietf-core-oscore-groupcomm] MUST be used.
Like defined in Section 7.2.1 for the phantom registration request,
the server protects the phantom cancellation request as per
Section 8.1 of [I-D.ietf-core-oscore-groupcomm], by using its Sender
Context and consuming its current Sender Sequence number in the
OSCORE group, from its Sender Context. The following, corresponding
multicast error response defined in Section 2.5 is also protected
with Group OSCORE, as per Section 8.3 of with Group OSCORE, as per Section 8.3 of
[I-D.ietf-core-oscore-groupcomm]. [I-D.ietf-core-oscore-groupcomm]. The server MUST use its own Sender
Sequence Number as Partial IV to protect the error response, and
Note that, differently from the multicast notifications, this include it as Partial IV in the OSCORE option of the response.
multicast error response will be the only one securely paired with
the phantom cancellation request.
7.3. Client-Side Requirements 7.3. Client-Side Requirements
When using Group OSCORE to protect multicast notifications, the When using Group OSCORE to protect multicast notifications, the
client performs as described in Section 3, with the following client performs as described in Section 3, with the following
differences. differences.
7.3.1. Informative Response 7.3.1. Informative Response
Upon receiving the informative response from the server, the client Upon receiving the informative response from the server, the client
skipping to change at page 29, line 42 skipping to change at page 30, line 26
succeed, or to step 6 otherwise. succeed, or to step 6 otherwise.
7.3.2. Notifications 7.3.2. Notifications
After having successfully processed the informative response as After having successfully processed the informative response as
defined in Section 7.3.1, the client will decrypt and verify every defined in Section 7.3.1, the client will decrypt and verify every
multicast notification for the target resource as defined in multicast notification for the target resource as defined in
Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following Section 8.4 of [I-D.ietf-core-oscore-groupcomm], with the following
difference. difference.
The client MUST set the two 'external_aad' defined in Sections 4.3.1 For both decryption and signature verification, the client MUST set
and 4.3.2 of [I-D.ietf-core-oscore-groupcomm] as follows. The the 'external_aad' defined in Section 4.3 of
particular way to achieve this is implementation specific. [I-D.ietf-core-oscore-groupcomm] as follows. The particular way to
achieve this is implementation specific.
* 'request_kid' takes the value of the 'kid' field from the OSCORE * 'request_kid' takes the value of the 'kid' field from the OSCORE
option of the phantom registration request (see Section 7.3.1). option of the phantom registration request (see Section 7.3.1).
* 'request_piv' takes the value of the 'piv' field from the OSCORE * 'request_piv' takes the value of the 'piv' field from the OSCORE
option of the phantom registration request (see Section 7.3.1). option of the phantom registration request (see Section 7.3.1).
* 'request_kid_context' takes the value of the 'kid context' field * 'request_kid_context' takes the value of the 'kid context' field
from the OSCORE option of the phantom registration request (see from the OSCORE option of the phantom registration request (see
Section 7.3.1). Section 7.3.1).
skipping to change at page 31, line 15 skipping to change at page 32, line 5
* 'OPT' denotes a sequence of CoAP options. This refers to the * 'OPT' denotes a sequence of CoAP options. This refers to the
phantom registration request encoded by the 'ph_req' parameter, or phantom registration request encoded by the 'ph_req' parameter, or
to the corresponding latest multicast notification encoded by the to the corresponding latest multicast notification encoded by the
'last_notif' parameter. 'last_notif' parameter.
* 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the * 'PAYLOAD' denotes an encrypted CoAP payload. This refers to the
phantom registration request encoded by the 'ph_req' parameter, or phantom registration request encoded by the 'ph_req' parameter, or
to the corresponding latest multicast notification encoded by the to the corresponding latest multicast notification encoded by the
'last_notif' parameter. 'last_notif' parameter.
* 'SIGN' denotes the counter signature appended to an encrypted CoAP * 'SIGN' denotes the signature appended to an encrypted CoAP
payload. This refers to the phantom registration request encoded payload. This refers to the phantom registration request encoded
by the 'ph_req' parameter, or to the corresponding latest by the 'ph_req' parameter, or to the corresponding latest
multicast notification encoded by the 'last_notif' parameter. multicast notification encoded by the 'last_notif' parameter.
C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r C_1 ------------ [ Unicast w/ OSCORE ] ------------------> S /r
| 0.05 (FETCH) | | 0.05 (FETCH) |
| Token: 0x4a | | Token: 0x4a |
| OSCORE: {kid: 1 ; piv: 101 ; ...} | | OSCORE: {kid: 1; piv: 101; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 0x01 (GET), | | 0x01 (GET), |
| Observe: 0 (Register), | | Observe: 0 (Register), |
| <Other class E options> | | <Other class E options> |
| } | | } |
| | | |
| (S allocates the available Token value 0x7b .) | | (S allocates the available Token value 0x7b .) |
| | | |
skipping to change at page 31, line 34 skipping to change at page 32, line 24
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 0x01 (GET), | | 0x01 (GET), |
| Observe: 0 (Register), | | Observe: 0 (Register), |
| <Other class E options> | | <Other class E options> |
| } | | } |
| | | |
| (S allocates the available Token value 0x7b .) | | (S allocates the available Token value 0x7b .) |
| | | |
| | | |
| (S sends to itself a phantom observation request PH_REQ | | (S sends to itself a phantom observation request PH_REQ |
| as coming from the IP multicast address GRP_ADDR .) | | as coming from the IP multicast address GRP_ADDR .) |
| ------------------------------------------------------ | | ------------------------------------------------------ |
| / | | / |
| \-------------------------------------------------------> | /r | \-------------------------------------------------------> | /r
| 0.05 (FETCH) | | 0.05 (FETCH) |
| Token: 0x7b | | Token: 0x7b |
| OSCORE: {kid: 5 ; piv: 501 ; | | OSCORE: {kid: 5 ; piv: 501; |
| kid context: 57ab2e; ...} | | kid context: 57ab2e; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 0x01 (GET), | | 0x01 (GET), |
| Observe: 0 (Register), | | Observe: 0 (Register), |
| <Other class E options> | | <Other class E options> |
| } | | } |
| <Counter signature> | | <Signature> |
| | | |
| | | |
| (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) | | (S steps SN_5 in the Group OSCORE Sec. Ctx : SN_5 <== 502) |
| | | |
| (S creates a group observation of /r .) | | (S creates a group observation of /r .) |
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
| | | |
| |
C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S C_1 <--------------- [ Unicast w/ OSCORE ] ---------------- S
| 2.05 (Content) | | 2.05 (Content) |
| Token: 0x4a | | Token: 0x4a |
| OSCORE: {piv: 301; ...} | | OSCORE: {piv: 301; ...} |
| Max-Age: 0 |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 5.03 (Service Unavailable), | | 5.03 (Service Unavailable), |
| Content-Format: application/informative-response+cbor, | | Content-Format: application/informative-response+cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_payload { | | CBOR_payload { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), |
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), |
| join_uri : "coap://myGM/ace-group/myGroup", | | join_uri : "coap://myGM/ace-group/myGroup", |
| sec_gp : "myGroup" | | sec_gp : "myGroup" |
| } | | } |
| } | | } |
| | | |
| |
C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r C_2 ------------ [ Unicast w/ OSCORE ] ------------------> S /r
| 0.05 (FETCH) | | 0.05 (FETCH) |
| Token: 0x01 | | Token: 0x01 |
| OSCORE: {kid: 2 ; piv: 201 ; ...} | | OSCORE: {kid: 2; piv: 201; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 0x01 (GET), | | 0x01 (GET), |
| Observe: 0 (Register), | | Observe: 0 (Register), |
| <Other class E options> | | <Other class E options> |
| } | | } |
| | | |
| (S increments the observer counter | | (S increments the observer counter |
| for the group observation of /r .) | | for the group observation of /r .) |
| | | |
C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S C_2 <--------------- [ Unicast w/ OSCORE ] ---------------- S
| 2.05 (Content) | | 2.05 (Content) |
| Token: 0x01 | | Token: 0x01 |
| OSCORE: {piv: 401; ...} | | OSCORE: {piv: 401; ...} |
| Max-Age: 0 |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff, | | 0xff, |
| Encrypted_payload { | | Encrypted_payload { |
| 5.03 (Service Unavailable), | | 5.03 (Service Unavailable), |
| Content-Format: application/informative-response+cbor, | | Content-Format: application/informative-response+cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_payload { | | CBOR_payload { |
| tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, |
| 0x7b, bstr(GRP_ADDR), GRP_PORT], | | 0x7b, bstr(GRP_ADDR), GRP_PORT], |
| ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), | | ph_req : bstr(0x05 | OPT | 0xff | PAYLOAD | SIGN), |
| last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), | | last_notif : bstr(0x45 | OPT | 0xff | PAYLOAD | SIGN), |
| join_uri : "coap://myGM/ace-group/myGroup", | | join_uri : "coap://myGM/ace-group/myGroup", |
| sec_gp : "myGroup" | | sec_gp : "myGroup" |
| } | | } |
| } | | } |
| | | |
| |
| (The value of the resource /r changes to "5678".) | | (The value of the resource /r changes to "5678".) |
| | | |
C_1 | C_1 |
+ <----------- [ Multicast w/ Group OSCORE ] ------------ S + <----------- [ Multicast w/ Group OSCORE ] ------------ S
C_2 (Destination address/port: GRP_ADDR/GRP_PORT) | C_2 (Destination address/port: GRP_ADDR/GRP_PORT) |
| 2.05 (Content) | | 2.05 (Content) |
| Token: 0x7b | | Token: 0x7b |
| OSCORE: {kid: 5; piv: 502 ; | | OSCORE: {kid: 5; piv: 502; |
| kid context: 57ab2e; ...} | | kid context: 57ab2e; ...} |
| <Other class U/I options> | | <Other class U/I options> |
| 0xff | | 0xff |
| Encrypted_payload { | | Encrypted_payload { |
| 2.05 (Content), | | 2.05 (Content), |
| Observe: 11, | | Observe: [empty], |
| Content-Format: application/cbor, | | Content-Format: application/cbor, |
| <Other class E options>, | | <Other class E options>, |
| 0xff, | | 0xff, |
| CBOR_Payload : "5678" | | CBOR_Payload : "5678" |
| } | | } |
| <Counter signature> | | <Signature> |
| | | |
Figure 7: Example of group observation with Group OSCORE Figure 7: Example of group observation with Group OSCORE
The two external_aad used to encrypt and countersign the multicast The two external_aad used to encrypt and sign the multicast
notification above have 'request_kid' = 5, 'request_piv' = 501 and notification above have 'request_kid' = 5, 'request_piv' = 501 and
'request_kid_context' = 0x57ab2e. These values are specified in the 'request_kid_context' = 0x57ab2e. These values are specified in the
'kid', 'piv' and 'kid context' field of the OSCORE option of the 'kid', 'piv' and 'kid context' field of the OSCORE option of the
phantom observation request, which is encoded in the 'ph_req' phantom observation request, which is encoded in the 'ph_req'
parameter of the unicast informative response to the two clients. parameter of the unicast informative response to the two clients.
Thus, the two clients can build the two same external_aad for Thus, the two clients can build the two same external_aad for
decrypting and verifying this multicast notification and the decrypting and verifying this multicast notification and the
following ones. following ones.
9. Intermediaries 9. Intermediaries
skipping to change at page 36, line 30 skipping to change at page 37, line 17
performs a new observe registration request, by transmitting the re- performs a new observe registration request, by transmitting the re-
built phantom request as intended to reach the proxy adjacent to the built phantom request as intended to reach the proxy adjacent to the
origin server. In particular, the client includes the new Listen-To- origin server. In particular, the client includes the new Listen-To-
Multicast-Responses CoAP option defined in Section 10.1, to provide Multicast-Responses CoAP option defined in Section 10.1, to provide
that proxy with the transport-specific information required for that proxy with the transport-specific information required for
receiving multicast notifications for the group observation. receiving multicast notifications for the group observation.
Details on the additional message exchange and processing are defined Details on the additional message exchange and processing are defined
in Section 10.2. in Section 10.2.
10.1. The Listen-To-Multicast-Responses Option 10.1. Listen-To-Multicast-Responses Option
To allow the proxy to listen to the multicast notifications sent by In order to allow the proxy to listen to the multicast notifications
the server, a new CoAP option is introduced. This option MUST be sent by the server, a new CoAP option is introduced. This option
supported by clients interested to take part in group observations MUST be supported by clients interested to take part in group
through intermediaries, and by proxies that collect multicast observations through intermediaries, and by proxies that collect
notifications and forward them back to the observer clients. multicast notifications and forward them back to the observer
clients.
The option is called Listen-To-Multicast-Responses and is intended The option is called Listen-To-Multicast-Responses and is intended
only for requests. As summarized in Figure 8, the option is critical only for requests. As summarized in Figure 8, the option is critical
and proxy-unsafe. and not Safe-to-Forward. Since the option is not Safe-to-Forward,
the column "N" indicates a dash for "not applicable".
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Len. | Default | | No. | C | U | N | R | Name | Format | Len. | Default |
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
| TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) | | TBD | x | x | - | | Listen-To- | (*) | 3-1024 | (none) |
| | | | | | Multicast- | | | | | | | | | | Multicast- | | | |
| | | | | | Responses | | | | | | | | | | Responses | | | |
+-----+---+---+---+---+-------------------+--------+--------+---------+ +-----+---+---+---+---+-------------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
skipping to change at page 37, line 45 skipping to change at page 38, line 35
* The client builds a ticket request (see Appendix B of * The client builds a ticket request (see Appendix B of
[I-D.amsuess-core-cachable-oscore]), as intended to reach the [I-D.amsuess-core-cachable-oscore]), as intended to reach the
proxy adjacent to the origin server. The ticket request is proxy adjacent to the origin server. The ticket request is
formatted as follows. formatted as follows.
- The Token is chosen as the client sees fit. In fact, there is - The Token is chosen as the client sees fit. In fact, there is
no reason for this Token to be the same as the phantom no reason for this Token to be the same as the phantom
request's. request's.
- The Code field, the outer CoAP options and the encrypted - The outer Code field, the outer CoAP options and the encrypted
payload (containing inner options, AEAD tag etc.) are the same payload with AEAD tag (protecting the inner Code, the inner
of the phantom request used for the group observation. That CoAP options and the possible plain CoAP payload) concatenated
is, they are as specified in the 'ph_req' parameter of the with the signature are the same of the phantom request used for
received informative response. the group observation. That is, they are as specified in the
'ph_req' parameter of the received informative response.
- An outer Observe option is included and set to 0 (Register). - An outer Observe option is included and set to 0 (Register).
This will usually be set in the phantom request already. This will usually be set in the phantom request already.
- The outer options Proxy-Scheme, Uri-Host and Uri-Port are - The outer options Proxy-Scheme, Uri-Host and Uri-Port are
included, and set to the same values they had in the original included, and set to the same values they had in the original
registration request sent by the client. registration request sent by the client.
- The new option Listen-To-Multicast-Responses is included as an - The new option Listen-To-Multicast-Responses is included as an
outer option. The value is set to the serialization of the outer option. The value is set to the serialization of the
CBOR array specified by the 'tp_info' parameter of the CBOR array specified by the 'tp_info' parameter of the
informative response. informative response.
Note that, except for transport-specific information such as Note that, except for transport-specific information such as
the Token and Message ID values, every different client the Token and Message ID values, every different client
participating to the same group observation (hence rebuilding participating to the same group observation (hence rebuilding
the same phantom request) will build the same ticket request. the same phantom request) will build the same ticket request.
Note also that, identically to the phantom request, the ticket Note also that, identically to the phantom request, the ticket
request is still protected with Group OSCORE, i.e. it has the request is still protected with Group OSCORE, i.e., it has the
same OSCORE option, encrypted payload and counter signature. same OSCORE option, encrypted payload and signature.
Then, the client sends the ticket request to the next hop towards the Then, the client sends the ticket request to the next hop towards the
origin server. Every proxy in the chain forwards the ticket request origin server. Every proxy in the chain forwards the ticket request
to the next hop towards the origin server, until the last proxy in to the next hop towards the origin server, until the last proxy in
the chain is reached. This last proxy, adjacent to the origin the chain is reached. This last proxy, adjacent to the origin
server, proceeds as follows. server, proceeds as follows.
* The proxy MUST NOT further forward the ticket request to the * The proxy MUST NOT further forward the ticket request to the
origin server. origin server.
skipping to change at page 38, line 43 skipping to change at page 39, line 34
from the ticket request. from the ticket request.
* The proxy removes the Listen-To-Multicast-Responses option from * The proxy removes the Listen-To-Multicast-Responses option from
the ticket request, and extracts the conveyed transport-specific the ticket request, and extracts the conveyed transport-specific
information. information.
* The proxy rebuilds the phantom request associated to the group * The proxy rebuilds the phantom request associated to the group
observation, by using the ticket request as directly providing the observation, by using the ticket request as directly providing the
required transport-independent information. This includes the required transport-independent information. This includes the
outer Code field, the outer CoAP options and the encrypted payload outer Code field, the outer CoAP options and the encrypted payload
concatenated with the counter signature. with AEAD tag concatenated with the signature.
* The proxy configures an observation of the target resource at the * The proxy configures an observation of the target resource at the
origin server, acting as a client directly taking part in the origin server, acting as a client directly taking part in the
group observation. To this end, the proxy uses the rebuilt group observation. To this end, the proxy uses the rebuilt
phantom request and the transport-specific information retrieved phantom request and the transport-specific information retrieved
from the Listen-To-Multicast-Responses Option. The particular way from the Listen-To-Multicast-Responses Option. The particular way
to achieve this is implementation specific. to achieve this is implementation specific.
After that, the proxy will listen to the IP multicast address and After that, the proxy will listen to the IP multicast address and
port number indicated in the Listen-To-Multicast-Responses option, as port number indicated in the Listen-To-Multicast-Responses option, as
'cli_addr' and 'cli_port' element of the serialized CBOR array, 'cli_addr' and 'cli_port' element of the serialized CBOR array,
respectively. Furthermore, multicast notifications will match the respectively. Furthermore, multicast notifications will match the
phantom request stored at the proxy, based on the Token value phantom request stored at the proxy, based on the Token value
specified in the 'token' element of the serialized CBOR array in the specified in the 'token' element of the serialized CBOR array in the
Listen-To-Multicast-Responses option. Listen-To-Multicast-Responses option.
An example is provided in Appendix F. An example is provided in Appendix F.
11. Informative Response Parameters 11. Informative Response Parameters
This specification defines a number of fields used in the informative This document defines a number of fields used in the informative
response message defined in Section 2.2. response message defined in Section 2.2.
The table below summarizes them and specifies the CBOR key to use The table below summarizes them and specifies the CBOR key to use
instead of the full descriptive name. Note that the media type instead of the full descriptive name. Note that the media type
application/informative-response+cbor MUST be used when these fields application/informative-response+cbor MUST be used when these fields
are transported. are transported.
+================+==========+===================+=============+ +================+==========+===================+=============+
| Name | CBOR Key | CBOR Type | Reference | | Name | CBOR Key | CBOR Type | Reference |
+================+==========+===================+=============+ +================+==========+===================+=============+
| tp_info | 1 | array | Section 2.2 | | tp_info | 0 | array | Section 2.2 |
+----------------+----------+-------------------+-------------+
| ph_req | 2 | byte string | Section 2.2 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| last_notif | 3 | byte string | Section 2.2 | | ph_req | 1 | byte string | Section 2.2 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| join_uri | 4 | text string | Section 7.1 | | last_notif | 2 | byte string | Section 2.2 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| sec_gp | 5 | text string | Section 7.1 | | join_uri | 3 | text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| as_uri | 6 | text string | Section 7.1 | | sec_gp | 4 | text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| cs_alg | 7 | int / text string | Section 7.1 | | as_uri | 5 | text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| cs_crv | 8 | int / text string | Section 7.1 | | hkdf | 6 | int / text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| cs_kty | 9 | int / text string | Section 7.1 | | pub_key_enc | 7 | int | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| cs_kenc | 10 | int | Section 7.1 | | sign_enc_alg | 8 | int / text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| alg | 11 | int / text string | Section 7.1 | | sign_alg | 9 | int / text string | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| hkdf | 12 | int / text string | Section 7.1 | | sign_params | 10 | array | Section 7.1 |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| gp_material | 13 | map | Appendix C | | gp_material | 11 | map | Appendix C |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| srv_pub_key | 14 | byte string | Appendix C | | srv_pub_key | 12 | byte string | Appendix C |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| srv_identifier | 15 | byte string | Appendix C | | srv_identifier | 13 | byte string | Appendix C |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
| exp | 16 | uint | Appendix C | | exp | 14 | uint | Appendix C |
+----------------+----------+-------------------+-------------+ +----------------+----------+-------------------+-------------+
Table 1 Table 1
12. Transport Protocol Information 12. Transport Protocol Information
This specification defines some values of transport protocol This document defines some values of transport protocol identifiers
identifiers to use within the 'tp_info' parameter of the informative to use within the 'tp_info' parameter of the informative response
response message defined in Section 2.2 of this specification. message defined in Section 2.2.
According to the encoding specified in Section 2.2.1, these values According to the encoding specified in Section 2.2.1, these values
are used for the 'tp_id' element of 'srv_addr', under the 'tp_info' are used for the 'tp_id' element of 'srv_addr', under the 'tp_info'
parameter. parameter.
The table below summarizes them, specifies the integer value to use The table below summarizes them, specifies the integer value to use
instead of the full descriptive name, and provides the corresponding instead of the full descriptive name, and provides the corresponding
full set of information elements to include in the 'tp_info' full set of information elements to include in the 'tp_info'
parameter. parameter.
skipping to change at page 41, line 30 skipping to change at page 41, line 40
+-----------+-------------+-------+----------+-----------+-----------+ +-----------+-------------+-------+----------+-----------+-----------+
Figure 9: Transport protocol information Figure 9: Transport protocol information
13. Security Considerations 13. Security Considerations
The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor The same security considerations from [RFC7252][RFC7641][I-D.ietf-cor
e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for e-groupcomm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for
this document. this document.
If multicast notifications are protected using Group OSCORE, the If multicast notifications are protected using Group OSCORE as per
original registration requests and related unicast (notification) Section 7, the following applies.
responses MUST also be secured, including and especially the
informative responses from the server. This prevents on-path active * The original registration requests and related unicast
adversaries from altering the conveyed IP multicast address and (notification) responses MUST also be secured, including and
serialized phantom registration request. Thus, it ensures secure especially the informative responses from the server. This
binding between every multicast notification for a same observed prevents on-path active adversaries from altering the conveyed IP
resource and the phantom registration request that started the group multicast address and serialized phantom registration request.
observation of that resource. Thus, it ensures secure binding between every multicast
notification for a same observed resource and the phantom
registration request that started the group observation of that
resource.
* A re-registration request, possibly including the Multicast-
Response-Feedback-Divider option to support the rough counting of
clients (see Section 6), MUST also be secured.
To this end, clients and servers SHOULD use OSCORE or Group OSCORE, To this end, clients and servers SHOULD use OSCORE or Group OSCORE,
so ensuring that the secure binding above is enforced end-to-end so ensuring that the secure binding above is enforced end-to-end
between the server and each observing client. between the server and each observing client.
13.1. Listen-To-Multicast-Responses Option 13.1. Listen-To-Multicast-Responses Option
The CoAP option Listen-To-Multicast-Responses defined in Section 10.1 The CoAP option Listen-To-Multicast-Responses defined in Section 10.1
is of class U for OSCORE and Group OSCORE is of class U for OSCORE and Group OSCORE
[RFC8613][I-D.ietf-core-oscore-groupcomm]. [RFC8613][I-D.ietf-core-oscore-groupcomm].
skipping to change at page 42, line 36 skipping to change at page 43, line 7
In order to prevent what described above, the ticket requests In order to prevent what described above, the ticket requests
conveying the Listen-To-Multicast-Responses option can be conveying the Listen-To-Multicast-Responses option can be
additionally protected hop-by-hop. additionally protected hop-by-hop.
14. IANA Considerations 14. IANA Considerations
This document has the following actions for IANA. This document has the following actions for IANA.
14.1. Media Type Registrations 14.1. Media Type Registrations
This specification registers the media type 'application/informative- This document registers the media type 'application/informative-
response+cbor' for error messages as informative response defined in response+cbor' for error messages as informative response defined in
Section 2.2 of this specification, when carrying parameters encoded Section 2.2, when carrying parameters encoded in CBOR. This
in CBOR. This registration follows the procedures specified in registration follows the procedures specified in [RFC6838].
[RFC6838].
* Type name: application * Type name: application
* Subtype name: informative-response+cbor * Subtype name: informative-response+cbor
* Required parameters: N/A * Required parameters: N/A
* Optional parameters: N/A * Optional parameters: N/A
* Encoding considerations: Must be encoded as a CBOR map containing * Encoding considerations: Must be encoded as a CBOR map containing
skipping to change at page 43, line 31 skipping to change at page 43, line 49
* Intended usage: COMMON * Intended usage: COMMON
* Restrictions on usage: None * Restrictions on usage: None
* Author: Marco Tiloca marco.tiloca@ri.se * Author: Marco Tiloca marco.tiloca@ri.se
(mailto:marco.tiloca@ri.se) (mailto:marco.tiloca@ri.se)
* Change controller: IESG * Change controller: IESG
* Provisional registration? No
14.2. CoAP Content-Formats Registry 14.2. CoAP Content-Formats Registry
IANA is asked to add the following entry to the "CoAP Content- IANA is asked to add the following entry to the "CoAP Content-
Formats" sub-registry defined in Section 12.3 of [RFC7252], within Formats" sub-registry defined in Section 12.3 of [RFC7252], within
the "Constrained RESTful Environments (CoRE) Parameters" registry. the "Constrained RESTful Environments (CoRE) Parameters" registry.
Media Type: application/informative-response+cbor Media Type: application/informative-response+cbor
Encoding: - Encoding: -
ID: TBD ID: TBD
Reference: [this document] Reference: [this document]
14.3. Informative Response Parameters Registry 14.3. Informative Response Parameters Registry
This specification establishes the "Informative Response Parameters" This document establishes the "Informative Response Parameters" IANA
IANA registry. The registry has been created to use the "Expert registry. The registry has been created to use the "Expert Review
Review Required" registration procedure [RFC8126]. Expert review Required" registration procedure [RFC8126]. Expert review guidelines
guidelines are provided in Section 14.6. are provided in Section 14.6.
The columns of this registry are: The columns of this registry are:
* Name: This is a descriptive name that enables easier reference to * Name: This is a descriptive name that enables easier reference to
the item. The name MUST be unique. It is not used in the the item. The name MUST be unique. It is not used in the
encoding. encoding.
* CBOR Key: This is the value used as CBOR key of the item. These * CBOR Key: This is the value used as CBOR key of the item. These
values MUST be unique. The value can be a positive integer, a values MUST be unique. The value can be a positive integer, a
negative integer, or a string. negative integer, or a string.
skipping to change at page 44, line 26 skipping to change at page 45, line 7
* Reference: This contains a pointer to the public specification for * Reference: This contains a pointer to the public specification for
the item. the item.
This registry has been initially populated by the values in This registry has been initially populated by the values in
Section 11. The "Reference" column for all of these entries refers Section 11. The "Reference" column for all of these entries refers
to sections of this document. to sections of this document.
14.4. CoAP Transport Information Registry 14.4. CoAP Transport Information Registry
This specification defines the subregistry "CoAP Transport This document defines the subregistry "CoAP Transport Information"
Information" within the "CoRE Parameters" registry. The registry has within the "CoRE Parameters" registry. The registry has been created
been created to use the "Expert Review Required" registration to use the "Expert Review Required" registration procedure [RFC8126].
procedure [RFC8126]. Expert review guidelines are provided in Expert review guidelines are provided in Section 14.6. It should be
Section 14.6. noted that, in addition to the expert review, some portions of the
Registry require a specification, potentially a Standards Track RFC,
to be supplied as well.
The columns of this registry are: The columns of this registry are:
* Transport Protocol: This is a descriptive name that enables easier * Transport Protocol: This is a descriptive name that enables easier
reference to the item. The name MUST be unique. It is not used reference to the item. The name MUST be unique. It is not used
in the encoding. in the encoding.
* Description: Text giving an overview of the transport protocol * Description: Text giving an overview of the transport protocol
referred by this item. referred by this item.
skipping to change at page 46, line 27 skipping to change at page 47, line 10
15. References 15. References
15.1. Normative References 15.1. Normative References
[COSE.Algorithms] [COSE.Algorithms]
IANA, "COSE Algorithms", IANA, "COSE Algorithms",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/
cose.xhtml#algorithms>. cose.xhtml#algorithms>.
[COSE.Elliptic.Curves] [COSE.Header.Parameters]
IANA, "COSE Elliptic Curves", IANA, "COSE Header Parameters",
<https://www.iana.org/assignments/cose/ <https://www.iana.org/assignments/cose/cose.xhtml#header-
cose.xhtml#elliptic-curves>. parameters>.
[COSE.Key.Types] [COSE.Key.Types]
IANA, "COSE Key Types", IANA, "COSE Key Types",
<https://www.iana.org/assignments/cose/cose.xhtml#key- <https://www.iana.org/assignments/cose/cose.xhtml#key-
type>. type>.
[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", Work in Progress, Internet- for OSCORE Groups in ACE", Work in Progress, Internet-
Draft, draft-ietf-ace-key-groupcomm-oscore-09, 2 November Draft, draft-ietf-ace-key-groupcomm-oscore-11, 12 July
2020, <http://www.ietf.org/internet-drafts/draft-ietf-ace- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-key-
key-groupcomm-oscore-09.txt>. groupcomm-oscore-11.txt>.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
"OSCORE Profile of the Authentication and Authorization "OSCORE Profile of the Authentication and Authorization
for Constrained Environments Framework", Work in Progress, for Constrained Environments Framework", Work in Progress,
Internet-Draft, draft-ietf-ace-oscore-profile-15, 26 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May
January 2021, <http://www.ietf.org/internet-drafts/draft- 2021, <https://www.ietf.org/archive/id/draft-ietf-ace-
ietf-ace-oscore-profile-15.txt>. oscore-profile-19.txt>.
[I-D.ietf-core-groupcomm-bis] [I-D.ietf-core-groupcomm-bis]
Dijk, E., Wang, C., and M. Tiloca, "Group Communication Dijk, E., Wang, C., and M. Tiloca, "Group Communication
for the Constrained Application Protocol (CoAP)", Work in for the Constrained Application Protocol (CoAP)", Work in
Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
02, 2 November 2020, <http://www.ietf.org/internet-drafts/ 04, 12 July 2021, <https://www.ietf.org/archive/id/draft-
draft-ietf-core-groupcomm-bis-02.txt>. ietf-core-groupcomm-bis-04.txt>.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
"Group OSCORE - Secure Group Communication for CoAP", Work and J. Park, "Group OSCORE - Secure Group Communication
in Progress, Internet-Draft, draft-ietf-core-oscore- for CoAP", Work in Progress, Internet-Draft, draft-ietf-
groupcomm-10, 2 November 2020, <http://www.ietf.org/ core-oscore-groupcomm-12, 12 July 2021,
internet-drafts/draft-ietf-core-oscore-groupcomm-10.txt>. <https://www.ietf.org/archive/id/draft-ietf-core-oscore-
groupcomm-12.txt>.
[I-D.ietf-cose-rfc8152bis-algs]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-algs-12.txt>.
[I-D.ietf-cose-rfc8152bis-struct]
Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", Work in Progress, Internet-Draft,
draft-ietf-cose-rfc8152bis-struct-14, 24 September 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-cose-
rfc8152bis-struct-14.txt>.
[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>.
[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>.
skipping to change at page 48, line 45 skipping to change at page 49, line 18
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
15.2. Informative References 15.2. Informative References
[I-D.amsuess-core-cachable-oscore] [I-D.amsuess-core-cachable-oscore]
Amsuess, C. and M. Tiloca, "Cachable OSCORE", Work in Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
Progress, Internet-Draft, draft-amsuess-core-cachable- Progress, Internet-Draft, draft-amsuess-core-cachable-
oscore-00, 13 July 2020, <http://www.ietf.org/internet- oscore-01, 22 February 2021,
drafts/draft-amsuess-core-cachable-oscore-00.txt>. <https://www.ietf.org/archive/id/draft-amsuess-core-
cachable-oscore-01.txt>.
[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)", Work in Progress, Internet-Draft, Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-36, 16 November 2020, draft-ietf-ace-oauth-authz-43, 10 July 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth- <https://www.ietf.org/archive/id/draft-ietf-ace-oauth-
authz-36.txt>. authz-43.txt>.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", Work in Progress, Internet-Draft, draft-ietf- (CoAP)", Work in Progress, Internet-Draft, draft-ietf-
core-coap-pubsub-09, 30 September 2019, core-coap-pubsub-09, 30 September 2019,
<http://www.ietf.org/internet-drafts/draft-ietf-core-coap- <https://www.ietf.org/archive/id/draft-ietf-core-coap-
pubsub-09.txt>. pubsub-09.txt>.
[I-D.ietf-core-coral] [I-D.ietf-core-coral]
Hartke, K., "The Constrained RESTful Application Language Hartke, K., "The Constrained RESTful Application Language
(CoRAL)", Work in Progress, Internet-Draft, draft-ietf- (CoRAL)", Work in Progress, Internet-Draft, draft-ietf-
core-coral-03, 9 March 2020, <http://www.ietf.org/ core-coral-03, 9 March 2020,
internet-drafts/draft-ietf-core-coral-03.txt>. <https://www.ietf.org/archive/id/draft-ietf-core-coral-
03.txt>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V.
Stok, "CoRE Resource Directory", Work in Progress, D. Stok, "CoRE Resource Directory", Work in Progress,
Internet-Draft, draft-ietf-core-resource-directory-26, 2 Internet-Draft, draft-ietf-core-resource-directory-28, 7
November 2020, <http://www.ietf.org/internet-drafts/draft- March 2021, <https://www.ietf.org/archive/id/draft-ietf-
ietf-core-resource-directory-26.txt>. core-resource-directory-28.txt>.
[I-D.ietf-cose-cbor-encoded-cert]
Raza, S., Höglund, J., Selander, G., Mattsson, J. P., and
M. Furuhed, "CBOR Encoded X.509 Certificates (C509
Certificates)", Work in Progress, Internet-Draft, draft-
ietf-cose-cbor-encoded-cert-01, 25 May 2021,
<https://www.ietf.org/archive/id/draft-ietf-cose-cbor-
encoded-cert-01.txt>.
[I-D.ietf-rats-uccs]
Birkholz, H., O'Donoghue, J., Cam-Winget, N., and C.
Bormann, "A CBOR Tag for Unprotected CWT Claims Sets",
Work in Progress, Internet-Draft, draft-ietf-rats-uccs-00,
19 May 2021, <https://www.ietf.org/archive/id/draft-ietf-
rats-uccs-00.txt>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-40, 20 January 2021, <http://www.ietf.org/internet- dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-40.txt>. drafts/draft-ietf-tls-dtls13-43.txt>.
[I-D.tiloca-core-oscore-discovery] [I-D.tiloca-core-oscore-discovery]
Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE Tiloca, M., Amsuess, C., and P. V. D. Stok, "Discovery of
Groups with the CoRE Resource Directory", Work in OSCORE Groups with the CoRE Resource Directory", Work in
Progress, Internet-Draft, draft-tiloca-core-oscore- Progress, Internet-Draft, draft-tiloca-core-oscore-
discovery-07, 2 November 2020, <http://www.ietf.org/ discovery-09, 12 July 2021,
internet-drafts/draft-tiloca-core-oscore-discovery- <https://www.ietf.org/archive/id/draft-tiloca-core-oscore-
07.txt>. discovery-09.txt>.
[MOBICOM99] [MOBICOM99]
Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The Ni, S.-Y., Tseng, Y.-C., Chen, Y.-S., and J.-P. Sheu, "The
Broadcast Storm Problem in a Mobile Ad Hoc Network", Broadcast Storm Problem in a Mobile Ad Hoc Network",
Proceedings of the 5th annual ACM/IEEE international Proceedings of the 5th annual ACM/IEEE international
conference on Mobile computing and networking , August conference on Mobile computing and networking , August
1999, <https://people.eecs.berkeley.edu/~culler/cs294- 1999, <https://people.eecs.berkeley.edu/~culler/cs294-
f03/papers/bcast-storm.pdf>. f03/papers/bcast-storm.pdf>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
skipping to change at page 50, line 25 skipping to change at page 51, line 13
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
Appendix A. Different Sources for Group Observation Data Appendix A. Different Sources for Group Observation Data
While the clients usually receive the phantom registration request While the clients usually receive the phantom registration request
and other information related to the group observation through an and other information related to the group observation through an
Informative Response, the same data can be made available through Informative Response, the same data can be made available through
different services, such as the following ones. different services, such as the following ones.
A.1. Topic Discovery in Publish-Subscribe Settings A.1. Topic Discovery in Publish-Subscribe Settings
In a Publish-Subscribe scenario ([I-D.ietf-core-coap-pubsub]), a In a Publish-Subscribe scenario [I-D.ietf-core-coap-pubsub], a group
group observation can be discovered along with topic metadata. For observation can be discovered along with topic metadata. For
instance, a discovery step can make the following metadata available. instance, a discovery step can make the following metadata available.
This example assumes a CoRAL namespace [I-D.ietf-core-coral], that This example assumes a CoRAL namespace [I-D.ietf-core-coral], that
contains properties analogous to those in the content-format contains properties analogous to those in the content-format
application/informative-response+cbor. application/informative-response+cbor.
Request: Request:
GET </ps/topics?rt=oic.r.temperature> GET </ps/topics?rt=oic.r.temperature>
Accept: CoRAL Accept: CoRAL
skipping to change at page 52, line 24 skipping to change at page 53, line 24
{ {
'tp_info': [1, h"7b", h"20010db80100..0001", 5683, 'tp_info': [1, h"7b", h"20010db80100..0001", 5683,
h"ff35003020010db8..1234", 5683], h"ff35003020010db8..1234", 5683],
'ph_req': h"0160..", 'ph_req': h"0160..",
'last_notif' : h"256105.." 'last_notif' : h"256105.."
} }
Figure 11: Group observation discovery with server introspection Figure 11: Group observation discovery with server introspection
For example, a network sniffer could offer sending such a request For example, a network sniffer could offer sending such a request
when unknown multicast notifications are seen on a network. when unknown multicast notifications are seen in a network.
Consequently, it can associate those notifications with a URI, or Consequently, it can associate those notifications with a URI, or
decrypt them, if member of the correct OSCORE group. decrypt them, if member of the correct OSCORE group.
Appendix B. Pseudo-Code for Rough Counting of Clients Appendix B. Pseudo-Code for Rough Counting of Clients
This appendix provides a description in pseudo-code of the two This appendix provides a description in pseudo-code of the two
algorithms used for the rough counting of active observers, as algorithms used for the rough counting of active observers, as
defined in Section 6. defined in Section 6.
In particular, Appendix B.1 describes the algorithm for the client In particular, Appendix B.1 describes the algorithm for the client
skipping to change at page 56, line 34 skipping to change at page 57, line 34
Group_OSCORE_Input_Material object, which is defined in Group_OSCORE_Input_Material object, which is defined in
Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore] and extends the
OSCORE_Input_Material object encoded in CBOR as defined in OSCORE_Input_Material object encoded in CBOR as defined in
Section 3.2.1 of [I-D.ietf-ace-oscore-profile]. Section 3.2.1 of [I-D.ietf-ace-oscore-profile].
In particular, the following elements of the In particular, the following elements of the
Group_OSCORE_Input_Material object are included, using the same Group_OSCORE_Input_Material object are included, using the same
CBOR labels from the OSCORE Security Context Parameters Registry, CBOR labels from the OSCORE Security Context Parameters Registry,
as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore]. as in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore].
- 'ms', 'contexId', 'cs_alg', 'cs_params', 'cs_key_params', - 'ms', 'contexId', 'pub_key_enc', 'sign_enc_alg', 'sign_alg' and
'cs_key_enc'. These elements MUST be included. 'sign_params'. These elements MUST be included.
- 'hkdf', 'alg', 'salt'. These elements MAY be included. - 'hkdf' and 'salt'. These elements MAY be included.
The following elements of the Group_OSCORE_Input_Material object The 'group_senderId' element of the Group_OSCORE_Input_Material
MUST NOT be included. object MUST NOT be included.
- 'group_senderId', 'ecdh_alg', 'ecdh_params', 'ecdh_key_params'. If the optimization defined in this appendix is combined with the
use of phantom requests as deterministic requests (see
Appendix D), the elements 'alg', 'ecdh_alg' and 'ecdh_params' of
the Group_OSCORE_Input_Material object MUST also be included.
Otherwise, they MUST NOT be included.
* 'srv_pub_key': this element is a CBOR byte string, which wraps the * 'srv_pub_key': this element is a CBOR byte string, which wraps the
serialization of the public key that the server uses in the OSCORE original binary representation of the server's public key used in
group. If the public key of the server is encoded as a COSE_Key the OSCORE group. In particular, the original binary
(see the 'cs_key_enc' element of the 'gp_material' parameter), it representation complies with the encoding specified by the
includes 'kid' specifying the Sender ID that the server has in the 'pub_key_enc' element of 'gp_material'.
OSCORE group.
* 'srv_identifier': this element MUST be present only if * 'srv_identifier': this element MUST be included and is encoded as
'srv_pub_key' is also present and, at the same time, the used a CBOR byte string, with value the Sender ID that the server has
encoding for the public key of the server does not allow to in the OSCORE group.
specify a Sender ID within the associated public key. Otherwise,
it MUST NOT be present. If present, this element is a CBOR byte
string, with value the Sender ID that the server has in the OSCORE
group.
* 'exp': with value the expiration time of the keying material of * 'exp': with value the expiration time of the keying material of
the OSCORE group specified in the 'gp_material' parameter, encoded the OSCORE group specified in the 'gp_material' parameter, encoded
as a CBOR unsigned integer. This field contains a numeric value as a CBOR unsigned integer. This field contains a numeric value
representing the number of seconds from 1970-01-01T00:00:00Z UTC representing the number of seconds from 1970-01-01T00:00:00Z UTC
until the specified UTC date/time, ignoring leap seconds, until the specified UTC date/time, ignoring leap seconds,
analogous to what specified for NumericDate in Section 2 of analogous to what specified for NumericDate in Section 2 of
[RFC7519]. [RFC7519].
Note that the informative response does not require to include an
explicit proof-of-possession (PoP) of the server's private key.
Although the server is also acting as Group Manager and a PoP
evidence of the Group Manager's private key is included in a full-
fledged Joining Response (see Section 6.4 of
[I-D.ietf-ace-key-groupcomm-oscore]), such proof-of-possession will
be achieved through every multicast notification, that the server
sends as protected with the group mode of Group OSCORE and including
a signature computed with its private key.
A client receiving an informative response uses the information above A client receiving an informative response uses the information above
to set up the Group OSCORE Security Context, as described in to set up the Group OSCORE Security Context, as described in
Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client Section 2 of [I-D.ietf-core-oscore-groupcomm]. Note that the client
does not obtain a Sender ID of its own, hence it installs a Security does not obtain a Sender ID of its own, hence it installs a Security
Context that a "silent server" would, i.e. without Sender Context. Context that a "silent server" would, i.e., without Sender Context.
From then on, the client uses the received keying material to process From then on, the client uses the received keying material to process
the incoming multicast notifications from the server. the incoming multicast notifications from the server.
The server complies with the following points. Since the server is also acting as Group Manager, the public key of
the server provided in the 'srv_pub_key' element of the informative
response is also used in the 'gm_public_key' element of the
external_aad for encrypting and signing the phantom request and
multicast notifications (see Section 4.3 of
[I-D.ietf-core-oscore-groupcomm])
Furthermore, the server complies with the following points.
* The server MUST NOT self-manage OSCORE groups and provide the * The server MUST NOT self-manage OSCORE groups and provide the
related keying material in the informative response for any other related keying material in the informative response for any other
purpose than the protection of group observations, as defined in purpose than the protection of group observations, as defined in
this document. this document.
The server MAY use the same self-managed OSCORE group to protect The server MAY use the same self-managed OSCORE group to protect
the phantom request and the multicast notifications of multiple the phantom request and the multicast notifications of multiple
group observations it hosts. group observations it hosts.
* The server MUST NOT provide in the informative response the keying * The server MUST NOT provide in the informative response the keying
material of other OSCORE groups it is or has been a member of. material of other OSCORE groups it is or has been a member of.
After the time indicated in the 'exp' field: After the time indicated in the 'exp' field:
* The server MUST stop using the keying material and MUST cancel the * The server MUST stop using the keying material and MUST cancel the
group observations for which that keying material is used (see group observations for which that keying material is used (see
Section 2.5). If the server creates a new group observation as a Section 2.5 and Section 7.2.4). If the server creates a new group
replacement or follow-up using the same OSCORE group: observation as a replacement or follow-up using the same OSCORE
group:
- The server MUST update the Master Secret. - The server MUST update the Master Secret.
- The server MUST update the ID Context (Gid). Consistently with - The server MUST update the ID Context used as Group Identifier
Section 2.3 of [I-D.ietf-core-oscore-groupcomm], the server (Gid), consistently with Section 3.2 of
MUST assign an ID Context that it has never assigned before in [I-D.ietf-core-oscore-groupcomm].
the OSCORE group.
- The server MAY update the Master Salt. - The server MAY update the Master Salt.
* The client MUST stop using the keying material and MAY re-register * The client MUST stop using the keying material and MAY re-register
the observation at the server. the observation at the server.
Before the key material has expired, the server can send a multicast Before the keying material has expired, the server can send a
response with response code 5.03 (Service Unavailable) to the multicast response with response code 5.03 (Service Unavailable) to
observing clients, protected with the current key material. In the observing clients, protected with the current keying material.
particular, this is an informative response (see Section 2.2) and In particular, this is an informative response (see Section 2.2),
contains the abovementioned parameters for the next group keying which additionally contains the abovementioned parameters for the
material to be used. Alternatively, the server can simply cancel the next group keying material to be used. The response has the same
group observation (see Section 2.5), which results in the eventual Token value T of the phantom registration request and it does not
re-registration of the clients that are still interested in the group include an Observe option. The server MUST use its own Sender
observation. Sequence Number as Partial IV to protect the error response, and
include it as Partial IV in the OSCORE option of the response.
When some clients leave the OSCORE group and forget about the group
observation, the server does not have to provide the remaining
clients with any stale Sender IDs, as normally required for Group
OSCORE (see Section 3.2 of [I-D.ietf-core-oscore-groupcomm]). In
fact, only two entities in the group have a Sender ID, i.e., the
server and possibly the Deterministic Client, if the optimization
defined in this appendix is combined with the use of phantom requests
as deterministic requests (see Appendix D). In particular, both of
them never change their Sender ID during the group lifetime, while
they both remain part of the group until the group ceases to exist.
As an alternative to renewing the keying material before it expires,
the server can simply cancel the group observation (see Section 2.5
and Section 7.2.4), which results in the eventual re-registration of
the clients that are still interested in the group observation.
Applications requiring backward security and forward security are Applications requiring backward security and forward security are
REQUIRED to use an actual group joining process (usually through a REQUIRED to use an actual group joining process (usually through a
dedicated Group Manager), e.g. the ACE joining procedure defined in dedicated Group Manager), e.g., the ACE joining procedure defined in
[I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the [I-D.ietf-ace-key-groupcomm-oscore]. The server can facilitate the
clients by providing them information about the OSCORE group to join, clients by providing them information about the OSCORE group to join,
as described in Section 7.1. as described in Section 7.1.
Appendix D. Phantom Request as Deterministic Request Appendix D. Phantom Request as Deterministic Request
In some settings, the server can assume that all the approaching In some settings, the server can assume that all the approaching
clients already have the exact phantom observation request to use. clients already have the exact phantom observation request to use.
For instance, the clients can be pre-configured with the phantom For instance, the clients can be pre-configured with the phantom
skipping to change at page 59, line 7 skipping to change at page 60, line 34
Deterministic Client [I-D.amsuess-core-cachable-oscore], then the Deterministic Client [I-D.amsuess-core-cachable-oscore], then the
server and each client in the OSCORE group can independently protect server and each client in the OSCORE group can independently protect
the phantom observation request possibly available as plain CoAP the phantom observation request possibly available as plain CoAP
message. To this end, they use the approach defined in Section 2 of message. To this end, they use the approach defined in Section 2 of
[I-D.amsuess-core-cachable-oscore] to compute a protected [I-D.amsuess-core-cachable-oscore] to compute a protected
deterministic request, against which the protected multicast deterministic request, against which the protected multicast
notifications will match for the group observation in question. notifications will match for the group observation in question.
Note that, if the optimization defined in Appendix C is also used, Note that, if the optimization defined in Appendix C is also used,
the error informative response from the server has to include the error informative response from the server has to include
additional information, i.e. the Sender ID of the Deterministic additional information, i.e., the Sender ID of the Deterministic
Client in the OSCORE group, and the hash algorithm used to compute Client in the OSCORE group, and the hash algorithm used to compute
the deterministic request (see Section 2.3.1 of the deterministic request (see Section 2.3.1 of
[I-D.amsuess-core-cachable-oscore]). [I-D.amsuess-core-cachable-oscore]).
This optimization allows the server to not provide the same full This optimization allows the server to not provide the same full
phantom observation request to each client in the error informative phantom observation request to each client in the error informative
response (see Section 2.2). That is, the informative response does response (see Section 2.2). That is, the informative response does
not need to include the 'ph_req' parameter, but only the 'tp_info' not need to convey the full phantom request in the 'ph_req'
parameter specifying the transport-specific information and parameter, but only the 'tp_info' parameter specifying the transport-
(optionally) the 'last_notif' parameter specifying the latest sent specific information and (optionally) the 'last_notif' parameter
multicast notification. specifying the latest sent multicast notification.
Appendix E. Example with a Proxy Appendix E. Example with a Proxy
This section provides an example when a proxy P is used between the This section provides an example when a proxy P is used between the
clients and the server. The same assumptions and notation used in clients and the server. The same assumptions and notation used in
Section 5 are used for this example. In addition, the proxy has Section 5 are used for this example. In addition, the proxy has
address PRX_ADDR and listens to the port number PRX_PORT. address PRX_ADDR and listens to the port number PRX_PORT.
Unless explicitly indicated, all messages transmitted on the wire are Unless explicitly indicated, all messages transmitted on the wire are
sent over unicast. sent over unicast.
C1 C2 P S C1 C2 P S
| | | | | | | |
| | | | (The value of the resource /r is "1234") | | | | (The value of the resource /r is "1234")
| | | | | | | |
+------------>| | Token: 0x4a +------------>| | Token: 0x4a
| GET | | | Observe: 0 (Register) | GET | | | Observe: 0 (Register)
| | | | Proxy-Uri: coap://sensor.example/r | | | | Proxy-Uri: coap://sensor.example/r
| | | | | | | |
| | +------->| Token: 0x5e | | +------->| Token: 0x5e
| | | GET | Observe: 0 (Register) | | | GET | Observe: 0 (Register)
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | | | | |
skipping to change at page 60, line 7 skipping to change at page 61, line 34
| | | | request PH_REQ as coming from the | | | | request PH_REQ as coming from the
| | | | IP multicast address GRP_ADDR) | | | | IP multicast address GRP_ADDR)
| | | | | | | |
| | | ------+ | | | ------+
| | | / | | | | / |
| | | \----->| Token: 0x7b | | | \----->| Token: 0x7b
| | | GET | Observe: 0 (Register) | | | GET | Observe: 0 (Register)
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | | | | |
| | | |
| | | | (S creates a group observation of /r) | | | | (S creates a group observation of /r)
| | | | | | | |
| | | | (S increments the observer counter | | | | (S increments the observer counter
| | | | for the group observation of /r) | | | | for the group observation of /r)
| | | | | | | |
| | | | | | | |
| | |<-------+ Token: 0x5e | | |<-------+ Token: 0x5e
| | | 5.03 | Content-Format: application/ | | | 5.03 | Content-Format: application/
| | | | informative-response+cbor | | | | informative-response+cbor
| | | | Max-Age: 0
| | | | <Other options> | | | | <Other options>
| | | | Payload: { | | | | Payload: {
| | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT, | | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT,
| | | | 0x7b, bstr(GRP_ADDR), | | | | 0x7b, bstr(GRP_ADDR),
| | | | GRP_PORT], | | | | GRP_PORT],
| | | | ph_req : bstr(0x01 | OPT), | | | | ph_req : bstr(0x01 | OPT),
| | | | last_notif : bstr(0x45 | OPT | | | | | last_notif : bstr(0x45 | OPT |
| | | | 0xff | PAYLOAD) | | | | 0xff | PAYLOAD)
| | | | } | | | | }
| | | | | | | |
| | | | (PAYLOAD in 'last_notif' : "1234") | | | | (PAYLOAD in 'last_notif' : "1234")
| | | | | | | |
| | | | | | | |
| | | | (The proxy starts listening to the | | | | (The proxy starts listening to the
| | | | GRP_ADDR address and the GRP_PORT port.) | | | | GRP_ADDR address and the GRP_PORT port.)
| | | | | | | |
| | | | (The proxy adds C1 to its list of observers.) | | | | (The proxy adds C1 to its list of observers.)
| | | | | | | |
| | | |
|<------------+ | Token: 0x4a |<------------+ | Token: 0x4a
| 2.05 | | | Content-Format: application/cbor | 2.05 | | | Observe: 54120
| | | | Content-Format: application/cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "1234" | | | | Payload: "1234"
| | | |
: : : : : : : :
: : : : : : : :
: : : : : : : :
| | | |
| | | |
| +----->| | Token: 0x01 | +----->| | Token: 0x01
| | GET | | Observe: 0 (Register) | | GET | | Observe: 0 (Register)
| | | | Proxy-Uri: coap://sensor.example/r | | | | Proxy-Uri: coap://sensor.example/r
| | | | | | | |
| | | | (The proxy has a fresh cache representation) | | | | (The proxy has a fresh cache representation)
| | | | | | | |
| |<-----+ | Token: 0x01 | |<-----+ | Token: 0x01
| | 2.05 | | Content-Format: application/cbor | | 2.05 | | Observe: 54120
| | | | Content-Format: application/cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "1234" | | | | Payload: "1234"
| | | | | | | |
| | | |
: : : : : : : :
: : : : (The value of the resource : : : : (The value of the resource
: : : : /r changes to "5678".) : : : : /r changes to "5678".)
: : : (*) : : : : :
| | | (*) |
| | |<-------+ Token: 0x7b | | |<-------+ Token: 0x7b
| | | 2.05 | Observe: 11 | | | 2.05 | Observe: 11
| | | | Content-Format: application/cbor | | | | Content-Format: application/cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
| | | | | | | |
|<------------+ | Token: 0x4a |<------------+ | Token: 0x4a
| 2.05 | | | Observe: 54123 | 2.05 | | | Observe: 54123
| | | | Content-Format: application/cbor | | | | Content-Format: application/cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
| | | | | | | |
| |<-----+ | Token: 0x01 | |<-----+ | Token: 0x01
| | 2.05 | | Observe: 54123 | | 2.05 | | Observe: 54123
| | | | Content-Format: application/cbor | | | | Content-Format: application/cbor
| | | | <Other options> | | | | <Other options>
| | | | Payload: "5678" | | | | Payload: "5678"
| | | |
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT
Figure 12: Example of group observation with a proxy Figure 12: Example of group observation with a proxy
Note that the proxy has all the information to understand the Note that the proxy has all the information to understand the
observation request from C2, and can immediately start to serve the observation request from C2, and can immediately start to serve the
still fresh values. still fresh values.
This behavior is mandated by Section 5 of [RFC7641], i.e. the proxy This behavior is mandated by Section 5 of [RFC7641], i.e., the proxy
registers itself only once with the next hop and fans out the registers itself only once with the next hop and fans out the
notifications it receives to all registered clients. notifications it receives to all registered clients.
Appendix F. Example with a Proxy and Group OSCORE Appendix F. Example with a Proxy and Group OSCORE
This section provides an example when a proxy P is used between the This section provides an example when a proxy P is used between the
clients and the server, and Group OSCORE is used to protect multicast clients and the server, and Group OSCORE is used to protect multicast
notifications end-to-end between the server and the clients. notifications end-to-end between the server and the clients.
The same assumptions and notation used in Section 8 are used for this The same assumptions and notation used in Section 8 are used for this
example. In addition, the proxy has address PRX_ADDR and listens to example. In addition, the proxy has address PRX_ADDR and listens to
the port number PRX_PORT. the port number PRX_PORT.
Unless explicitly indicated, all messages transmitted on the wire are Unless explicitly indicated, all messages transmitted on the wire are
sent over unicast and protected with OSCORE end-to-end between a sent over unicast and protected with OSCORE end-to-end between a
client and the server. client and the server.
C1 C2 P S C1 C2 P S
| | | | (The value of the resource /r is "1234") | | | |
| | | | (The value of the resource /r is "1234")
| | | | | | | |
+-------------->| | Token: 0x4a +-------------->| | Token: 0x4a
| FETCH | | | Observe: 0 (Register) | FETCH | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 1 ; piv: 101 ; ...} | | | | OSCORE: {kid: 1; piv: 101; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r, | | | | Uri-Path: r,
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | | | | |
| | +-------->| Token: 0x5e | | +-------->| Token: 0x5e
| | | FETCH | Observe: 0 (Register) | | | FETCH | Observe: 0 (Register)
| | | | OSCORE: {kid: 1 ; piv: 101 ; ...} | | | | OSCORE: {kid: 1; piv: 101; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r, | | | | Uri-Path: r,
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | | | | |
skipping to change at page 62, line 51 skipping to change at page 64, line 34
| | | | Token value 0x7b .) | | | | Token value 0x7b .)
| | | | | | | |
| | | | (S sends to itself a phantom observation | | | | (S sends to itself a phantom observation
| | | | request PH_REQ as coming from the | | | | request PH_REQ as coming from the
| | | | IP multicast address GRP_ADDR) | | | | IP multicast address GRP_ADDR)
| | | | | | | |
| | | -------+ | | | -------+
| | | / | | | | / |
| | | \------>| Token: 0x7b | | | \------>| Token: 0x7b
| | | FETCH | Observe: 0 (Register) | | | FETCH | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; | | | | OSCORE: {kid: 5; piv: 501;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r | | | | Uri-Path: r,
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | <Counter signature> | | | | <Signature>
| | | |
| | | | | | | |
| | | | (S steps SN_5 in the Group OSCORE | | | | (S steps SN_5 in the Group OSCORE
| | | | Security Context : SN_5 <== 502) | | | | Security Context : SN_5 <== 502)
| | | | | | | |
| | | | (S creates a group observation of /r) | | | | (S creates a group observation of /r)
| | | | | | | |
| | | |
| | | | (S increments the observer counter | | | | (S increments the observer counter
| | | | for the group observation of /r) | | | | for the group observation of /r)
| | | | | | | |
| | | |
| | |<--------+ Token: 0x5e | | |<--------+ Token: 0x5e
| | | 2.05 | OSCORE: {piv: 301 ; ...} | | | 2.05 | OSCORE: {piv: 301; ...}
| | | | Max-Age: 0
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 5.03 (Service Unavailable), | | | | 5.03 (Service Unavailable),
| | | | Content-Format: application/ | | | | Content-Format: application/
| | | | informative-response+cbor, | | | | informative-response+cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_payload { | | | | CBOR_payload {
| | | | tp_info : [1, bstr(SRV_ADDR), | | | | tp_info : [1, bstr(SRV_ADDR),
skipping to change at page 64, line 4 skipping to change at page 65, line 33
| | | | ph_req : bstr(0x05 | OPT | 0xff | | | | | ph_req : bstr(0x05 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x45 | OPT | 0xff | | | | | last_notif : bstr(0x45 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | join_uri : "coap://myGM/ | | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup", | | | | ace-group/myGroup",
| | | | sec_gp : "myGroup" | | | | sec_gp : "myGroup"
| | | | } | | | | }
| | | | } | | | | }
| | | | | | | |
| | | |
|<--------------+ | Token: 0x4a |<--------------+ | Token: 0x4a
| 2.05 | | | OSCORE: {piv: 301 ; ...} | 2.05 | | | OSCORE: {piv: 301; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | (Same Encrypted_payload) | | | | (Same Encrypted_payload)
| | | | | | | |
| | | |
+-------------->| | Token: 0x4b +-------------->| | Token: 0x4b
| FETCH | | | Observe: 0 (Register) | FETCH | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | OSCORE: {kid: 5 ; piv: 501;
| | | | kid context: 57ab2e; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | Listen-To- | | | | Listen-To-
| | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | | | | Multicast-Responses: {[1, bstr(SRV_ADDR),
| | | | SRV_PORT, 0x7b, | | | | SRV_PORT, 0x7b,
| | | | bstr(GRP_ADDR), | | | | bstr(GRP_ADDR),
| | | | GRP_PORT] | | | | GRP_PORT]
| | | | } | | | | }
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | <Counter signature> | | | | <Signature>
| | | | | | | |
| | | | | | | |
| | | | (The proxy starts listening to the | | | | (The proxy starts listening to the
| | | | GRP_ADDR address and the GRP_PORT port.) | | | | GRP_ADDR address and the GRP_PORT port.)
| | | | | | | |
| | | | (The proxy adds C1 to | | | | (The proxy adds C1 to
| | | | its list of observers.) | | | | its list of observers.)
| | | |
|<--------------| |
| | ACK | |
: : : : : : : :
: : : : : : : :
: : : : : : : :
| | | |
| +------>| | Token: 0x01 | +------>| | Token: 0x01
| | FETCH | | Observe: 0 (Register) | | FETCH | | Observe: 0 (Register)
| | | | OSCORE: {kid: 2 ; piv: 201 ; ...} | | | | OSCORE: {kid: 2; piv: 201; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r, | | | | Uri-Path: r,
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | | | | |
| | +-------->| Token: 0x5e | | +-------->| Token: 0x5f
| | | FETCH | Observe: 0 (Register) | | | FETCH | Observe: 0 (Register)
| | | | OSCORE: {kid: 2 ; piv: 201 ; ...} | | | | OSCORE: {kid: 2; piv: 201; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r, | | | | Uri-Path: r,
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | | | | |
| | |<--------+ Token: 0x5e | | |<--------+ Token: 0x5f
| | | 2.05 | OSCORE: {piv: 401 ; ...} | | | 2.05 | OSCORE: {piv: 401; ...}
| | | | Max-Age: 0
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 5.03 (Service Unavailable), | | | | 5.03 (Service Unavailable),
| | | | Content-Format: application/ | | | | Content-Format: application/
| | | | informative-response+cbor, | | | | informative-response+cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_payload { | | | | CBOR_payload {
| | | | tp_info : [1, bstr(SRV_ADDR), | | | | tp_info : [1, bstr(SRV_ADDR),
skipping to change at page 65, line 46 skipping to change at page 67, line 31
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | last_notif : bstr(0x45 | OPT | 0xff | | | | | last_notif : bstr(0x45 | OPT | 0xff |
| | | | PAYLOAD | SIGN), | | | | PAYLOAD | SIGN),
| | | | join_uri : "coap://myGM/ | | | | join_uri : "coap://myGM/
| | | | ace-group/myGroup", | | | | ace-group/myGroup",
| | | | sec_gp : "myGroup" | | | | sec_gp : "myGroup"
| | | | } | | | | }
| | | | } | | | | }
| | | | | | | |
| |<------+ | Token: 0x01 | |<------+ | Token: 0x01
| | 2.05 | | OSCORE: {piv: 401 ; ...} | | 2.05 | | OSCORE: {piv: 401; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | (Same Encrypted_payload) | | | | (Same Encrypted_payload)
| | | | | | | |
| | | |
| +------>| | Token: 0x02 | +------>| | Token: 0x02
| | FETCH | | Observe: 0 (Register) | | FETCH | | Observe: 0 (Register)
| | | | OSCORE: {kid: 5 ; piv: 501 ; ...} | | | | OSCORE: {kid: 5; piv: 501;
| | | | kid context: 57ab2e; ...}
| | | | Uri-Host: sensor.example | | | | Uri-Host: sensor.example
| | | | Proxy-Scheme: coap | | | | Proxy-Scheme: coap
| | | | Listen-To- | | | | Listen-To-
| | | | Multicast-Responses: {[1, bstr(SRV_ADDR), | | | | Multicast-Responses: {[1, bstr(SRV_ADDR),
| | | | SRV_PORT, 0x7b, | | | | SRV_PORT, 0x7b,
| | | | bstr(GRP_ADDR), | | | | bstr(GRP_ADDR),
| | | | GRP_PORT] | | | | GRP_PORT]
| | | | } | | | | }
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 0x01 (GET), | | | | 0x01 (GET),
| | | | Observe: 0 (Register), | | | | Observe: 0 (Register),
| | | | Uri-Path: r | | | | Uri-Path: r
| | | | <Other class E options> | | | | <Other class E options>
| | | | } | | | | }
| | | | <Counter signature> | | | | <Signature>
| | | | | | | |
| | | | (The proxy adds C2 to its list of | | | | (The proxy adds C2 to
| | | | observers, and serves the cached | | | | its list of observers.)
| | | | response) | |<------| |
| | ACK | |
| | | | | | | |
| |<------+ | Token: 0x02
| | 2.05 | | OSCORE: {piv: 301 ; ...}
| | | | <Other class U/I options>
| | | | 0xff
| | | | (Same as earlier to C1)
: : : :
: : : : : : : :
: : : : (The value of the resource
: : : : /r changes to "5678".)
: : : : : : : :
| | | | (The value of the resource
| | | | /r changes to "5678".)
| | | |
| | | |
| | | (*) | | | | (*) |
| | |<--------+ Token: 0x7b | | |<--------+ Token: 0x7b
| | | 2.05 | Observe: 11 | | | 2.05 | Observe: 11
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | Encrypted_payload { | | | | Encrypted_payload {
| | | | 2.05 (Content), | | | | 2.05 (Content),
| | | | Observe: 11, | | | | Observe: [empty],
| | | | Content-Format: application/cbor, | | | | Content-Format: application/cbor,
| | | | <Other class E options>, | | | | <Other class E options>,
| | | | 0xff, | | | | 0xff,
| | | | CBOR_Payload : "5678" | | | | CBOR_Payload : "5678"
| | | | } | | | | }
| | | | <Counter signature> | | | | <Signature>
| | | |
| | | | | | | |
|<--------------+ | Token: 0x4b |<--------------+ | Token: 0x4b
| 2.05 | | | Observe: 54123 | 2.05 | | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | (Same Encrypted_payload) | | | | (Same Encrypted_payload and Signature)
| | | | | | | |
| |<------+ | Token: 0x02 | |<------+ | Token: 0x02
| | 2.05 | | Observe: 54123 | | 2.05 | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; | | | | OSCORE: {kid: 5; piv: 502;
| | | | kid context: 57ab2e; ...} | | | | kid context: 57ab2e; ...}
| | | | <Other class U/I options> | | | | <Other class U/I options>
| | | | 0xff | | | | 0xff
| | | | (Same Encrypted_payload) | | | | (Same Encrypted_payload and signature)
| | | |
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected (*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected
with Group OSCORE end-to-end between the server and the clients. with Group OSCORE end-to-end between the server and the clients.
Figure 13: Example of group observation with a proxy and Group OSCORE Figure 13: Example of group observation with a proxy and Group OSCORE
Unlike in the unprotected example in Appendix E, the proxy does _not_ Unlike in the unprotected example in Appendix E, the proxy does _not_
have all the information to perform request deduplication, and can have all the information to perform request deduplication, and can
only recognize the identical request once the client sends the ticket only recognize the identical request once the client sends the ticket
request. request.
Appendix G. Example with a Proxy and Deterministic Requests
This section provides an example when a proxy P is used between the
clients and the server, and Group OSCORE is used to protect multicast
notifications end-to-end between the server and the clients.
In addition, the phantom request is especially a deterministic
request (see Appendix D), which is protected with the pairwise mode
of Group OSCORE as defined in [I-D.amsuess-core-cachable-oscore].
G.1. Assumptions and Walkthrough
The example provided in this appendix as reflected by the message
exchange shown in Appendix G.2 assumes the following.
1. The OSCORE group supports deterministic requests. Thus, the
server creates the phantom request as a deterministic request
[I-D.amsuess-core-cachable-oscore], and stores it locally as one
of its issued phantom requests, without starting the group
observation yet.
2. The server makes the phantom request available through other
means, e.g., a pub-sub broker, together with the transport-
specific information for listening to multicast notifications
bound to the phantom request (see Appendix A).
3. Since the phantom request is a deterministic request, the server
can more efficiently make it available in its smaller, plain
version. The clients can obtain it from the particular
alternative source, and compute the protected version to use
from the retrieved plain version.
4. If the client does not rely on a proxy between itself and the
server, it simply sets the group observation and starts
listening to multicast notifications. Building on point (2)
above, the same would happen if the phantom request would not be
specifically a deterministic request.
5. If the client relies on a proxy between itself and the server,
it uses the phantom request as a ticket request. However,
unlike the case considered in Section 10 when the ticket request
is not deterministic, the client does not include a Listen-to-
Multicast-Responses option in the phantom request sent to the
proxy.
6. Unlike for the case considered in Section 10, here the proxy
does not know that the request is exactly a ticket request for
subscribing to multicast notifications. Thus, the proxy simply
forwards the ticket request to the server as it normally does
for any request.
7. The server receives the ticket request, which is a deviation
from the case where the ticket request is not deterministic and
stops at the proxy (see Section 10). Then, the server can
clearly understand what is happening. In fact, as the result of
an early check, the server recognizes the phantom request among
the stored ones. This happens through a byte-by-byte comparison
of the incoming message minus the transport-related fields,
i.e., by considering only: i) the outer REST code; ii) the outer
options; and iii) the ciphertext and signature from the message
payload.
8. Having recognized the incoming request as one of the self-
generated deterministic phantom requests made available at
external sources, the server does not perform any OSCORE
processing on it. This opens for replying to the proxy with an
unprotected response, although not signaling any OSCORE-related
error.
9. The server starts the group observation and replies with an
error response, i.e., the usual 5.03 informative response,
including: the transport information, the phantom request, and
(optionally) the latest notification.
10. From the received 5.03 response, the proxy retrieves everything
needed to set itself as an observer in the group observation,
and it starts listening to multicast notifications. If the 5.03
response included a latest notification, the proxy caches it and
forwards it back to the client, otherwise it replies with an
empty ACK (if it has not done it already and the request from
the client was Confirmable).
11. Like in the case with a non-deterministic phantom request
considered in Section 10, the proxy fans out the multicast
notifications to the origin clients as they come. Also, as new
clients following the first one contact the proxy, this does not
have to contact the server again as in Section 10, since the
deterministic phantom request would produce a cache hit as per
[I-D.amsuess-core-cachable-oscore]. Thus, the proxy can serve
such clients with the latest fresh multicast notification from
its cache.
G.2. Message Exchange
The same assumptions and notation used in Section 8 are used for this
example. As a recap of some specific value:
* Two clients C_1 and C_2 register to observe a resource /r at a
Server S, which has address SRV_ADDR and listens to the port
number SRV_PORT. Before the following exchanges occur, no clients
are observing the resource /r , which has value "1234".
* The server S sends multicast notifications to the IP multicast
address GRP_ADDR and port number GRP_PORT, and starts the group
observation upon receiving a registration request from a first
client that wishes to start a traditional observation on the
resource /r.
* S is a member of the OSCORE group with 'kid context' = 0x57ab2e as
Group ID. In the OSCORE group, S has 'kid' = 5 as Sender ID, and
SN_5 = 501 as Sender Sequence Number.
In addition:
* The proxy has address PRX_ADDR and listens to the port number
PRX_PORT.
* The deterministic client in the OSCORE group has 'kid' 9.
Unless explicitly indicated, all messages transmitted on the wire are
sent over unicast and protected with Group OSCORE end-to-end between
a client and the server.
C1 C2 P S
| | | |
| | | | (The value of the resource /r is "1234")
| | | |
| | | | (The server prepares a deterministic
| | | | phantom request PH_REQ. The server
| | | | stores PH_REQ locally and makes it
| | | | available at an external source)
| | | |
| | | | (C1 obtains PH_REQ and sends it to P)
| | | |
| | | |
+-------------->| | Token: 0x4a
| FETCH | | | Uri-Host: sensor.example
| | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 9 ; piv: 0 ;
| | | | kid context: 0x57ab2e ; ... }
| | | | Proxy-Scheme: coap
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x01 (GET),
| | | | Observe: 0 (Register),
| | | | Uri-Path: r,
| | | | <Other class E options>
| | | | }
| | | |
| | +-------->| Token: 0x5e
| | | FETCH | Uri-Host: sensor.example
| | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 9 ; piv: 0 ;
| | | | kid context: 0x57ab2e ; ... }
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x01 (GET),
| | | | Observe: 0 (Register),
| | | | Uri-Path: r,
| | | | <Other class E options>
| | | | }
| | | |
| | | | (S recognizes PH_REQ through byte-by-byte
| | | | comparison against the stored one, and
| | | | skips any OSCORE processing)
| | | |
| | | | (S allocates the available
| | | | Token value 0x7b .)
| | | |
| | | | (S sends to itself PH_REQ, with Token 0x7b
| | | | and as coming from the IP multicast
| | | | address GRP_ADDR; now the OSCORE
| | | | processing does happen, as specified
| | | | for a deterministic request)
| | | |
| | | -------|
| | | / |
| | | \------>| Token: 0x7b
| | | FETCH | Uri-Host: sensor.example
| | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 9 ; piv: 0 ;
| | | | kid context: 0x57ab2e ; ... }
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x01 (GET),
| | | | Observe: 0 (Register),
| | | | Uri-Path: r,
| | | | <Other class E options>
| | | | }
| | | |
| | | | (S prepares the "last notification"
| | | | response defined below)
| | | |
| | | | 0x45 (2.05 Content)
| | | | Observe: 10
| | | | OSCORE: {kid: 5 ; piv: 501 ;
| | | | kid context: 57ab2e; ...}
| | | | Max-Age: 3000
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x45 (2.05 Content),
| | | | Observe: [empty],
| | | | Payload: "1234"
| | | | }
| | | |
| | | | (S responds to the proxy with an
| | | | unprotected informative response)
| | | |
| | |<--------| Token: 0x5e
| | | 5.03 | Content-Format: application/
| | | | informative-response+cbor
| | | | Max-Age: 0
| | | | 0xff,
| | | | CBOR_payload {
| | | | tp_info : [1, bstr(SRV_ADDR), SRV_PORT,
| | | | 0x7b, bstr(GRP_ADDR),
| | | | GRP_PORT],
| | | | ph_req : <the deterministic
| | | | phantom request>,
| | | | last_notif : <the "last notification"
| | | | response prepared above>
| | | | }
| | | | }
| | | |
| | | | (P extracts PH_REQ and starts listening
| | | | to multicast notifications with Token
| | | | 0x7b at GRP_ADDR:GRP_PORT)
| | | |
| | | | (P extracts the "last notification"
| | | | response, caches it and forwards
| | | | it back to C1)
| | | |
|<--------------+ | Token: 0x4a
| 2.05 | | | Observe: 54120
| | | | OSCORE: {kid: 5 ; piv: 501 ;
| | | | kid context: 57ab2e; ...}
| | | | Max-Age: 2995
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x45 (2.05 Content),
| | | | Observe: [empty],
| | | | Payload: "1234"
| | | | }
| | | |
: : : |
: : : |
: : : |
| | | |
| | | | (C2 obtains PH_REQ and sends it to P)
| | | |
| +------>| | Token: 0x01
| | FETCH | | Uri-Host: sensor.example
| | | | Observe: 0 (Register)
| | | | OSCORE: {kid: 9 ; piv: 0 ;
| | | | kid context: 57ab2e; ...}
| | | | Proxy-Scheme: coap
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x01 (GET),
| | | | Observe: 0 (Register),
| | | | Uri-Path: r,
| | | | <Other class E options>
| | | | }
| | | |
| | | | (P serves C2 from it cache)
| | | |
| |<------+ | Token: 0x01
| | 2.05 | | Observe: 54120
| | | | OSCORE: {kid: 5 ; piv: 501 ;
| | | | kid context: 57ab2e;
| | | | Max-Age: 1800
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x45 (2.05 Content),
| | | | Observe: [empty],
| | | | Payload: "1234"
| | | | }
| | | |
: : : |
: : : |
: : : |
| | | |
| | | | (The value of the resource
| | | | /r changes to "5678".)
| | | |
| | | (*) |
| | |<--------| Token: 0x7b
| | | 2.05 | Observe: 11
| | | | OSCORE: {kid: 5; piv: 502 ; ...}
| | | | <Other class U/I options>
| | | | 0xff
| | | | Encrypted_payload {
| | | | 0x45 (2.05 Content),
| | | | Observe: [empty],
| | | | Content-Format: application/cbor,
| | | | <Other class E options>,
| | | | 0xff,
| | | | CBOR_Payload : "5678"
| | | | }
| | | | <Signature>
| | | |
| | | | (P updates its cache entry
| | | | with this notification)
| | | |
|<--------------+ | Token: 0x4a
| 2.05 | | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; ...}
| | | | <Other class U/I options>
| | | | 0xff
| | | | (Same Encrypted_payload and signature)
| | | |
| |<------+ | Token: 0x01
| | 2.05 | | Observe: 54123
| | | | OSCORE: {kid: 5; piv: 502 ; ...}
| | | | <Other class U/I options>
| | | | 0xff
| | | | (Same Encrypted_payload and signature)
| | | |
(*) Sent over IP multicast to GROUP_ADDR:GROUP_PORT and protected
with Group OSCORE end-to-end between the server and the clients.
Appendix H. Document Updates
RFC EDITOR: PLEASE REMOVE THIS SECTION.
H.1. Version -00 to -01
* Simplified cancellation of the group observation, without using a
phantom cancellation request.
* Aligned parameter semantics with core-oscore-groupcomm and ace-
key-groupcomm-oscore.
* Clarifications about self-managed OSCORE group and use of
deterministic requests for cacheable OSCORE.
* New example with a proxy, Group OSCORE and a deterministic phantom
request.
* Fixes in the examples and editorial improvements.
Acknowledgments Acknowledgments
The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime
Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander
for their comments and feedback. for their comments and feedback.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652). (Grant agreement 952652).
skipping to change at page 68, line 4 skipping to change at page 76, line 38
The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime The authors sincerely thank Carsten Bormann, Klaus Hartke, Jaime
Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander Jimenez, John Mattsson, Ludwig Seitz, Jim Schaad and Goeran Selander
for their comments and feedback. for their comments and feedback.
The work on this document has been partly supported by VINNOVA and The work on this document has been partly supported by VINNOVA and
the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home
(Grant agreement 952652). (Grant agreement 952652).
Authors' Addresses Authors' Addresses
Marco Tiloca Marco Tiloca
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
SE-16440 Stockholm Kista SE-16440 Stockholm Kista
Sweden Sweden
Email: marco.tiloca@ri.se Email: marco.tiloca@ri.se
Rikard Höglund
Rikard Hoeglund
RISE AB RISE AB
Isafjordsgatan 22 Isafjordsgatan 22
SE-16440 Stockholm Kista SE-16440 Stockholm Kista
Sweden Sweden
Email: rikard.hoglund@ri.se Email: rikard.hoglund@ri.se
Christian Amsuess Christian Amsüss
Hollandstr. 12/4 Hollandstr. 12/4
1020 Vienna 1020 Vienna
Austria Austria
Email: christian@amsuess.com Email: christian@amsuess.com
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Torshamnsgatan 23 Torshamnsgatan 23
SE-16440 Stockholm Kista SE-16440 Stockholm Kista
 End of changes. 209 change blocks. 
429 lines changed or deleted 852 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/