draft-ietf-core-object-security-05.txt   draft-ietf-core-object-security-06.txt 
CoRE Working Group G. Selander CoRE Working Group G. Selander
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: April 2, 2018 Ericsson AB Expires: April 28, 2018 Ericsson AB
L. Seitz L. Seitz
SICS Swedish ICT SICS Swedish ICT
September 29, 2017 October 25, 2017
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-05 draft-ietf-core-object-security-06
Abstract Abstract
This document defines Object Security for Constrained RESTful This document defines Object Security for Constrained RESTful
Environments (OSCORE), a method for application-layer protection of Environments (OSCORE), a method for application-layer protection of
the Constrained Application Protocol (CoAP), using CBOR Object the Constrained Application Protocol (CoAP), using CBOR Object
Signing and Encryption (COSE). OSCORE provides end-to-end Signing and Encryption (COSE). OSCORE provides end-to-end
encryption, integrity and replay protection, as well as a secure encryption, integrity and replay protection, as well as a secure
message binding. OSCORE is designed for constrained nodes and message binding. OSCORE is designed for constrained nodes and
networks and can be used over any layer and across intermediaries, networks and can be used over any layer and across intermediaries,
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2018. This Internet-Draft will expire on April 28, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. The CoAP Object-Security Option . . . . . . . . . . . . . . . 5 2. The CoAP Object-Security Option . . . . . . . . . . . . . . . 5
3. The Security Context . . . . . . . . . . . . . . . . . . . . 6 3. The Security Context . . . . . . . . . . . . . . . . . . . . 6
3.1. Security Context Definition . . . . . . . . . . . . . . . 6 3.1. Security Context Definition . . . . . . . . . . . . . . . 6
3.2. Establishment of Security Context Parameters . . . . . . 8 3.2. Establishment of Security Context Parameters . . . . . . 9
3.3. Requirements on the Security Context Parameters . . . . . 10 3.3. Requirements on the Security Context Parameters . . . . . 11
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 11 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 11
4.1. CoAP Payload . . . . . . . . . . . . . . . . . . . . . . 12 4.1. CoAP Payload . . . . . . . . . . . . . . . . . . . . . . 12
4.2. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 12 4.2. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 12
4.3. CoAP Header . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. CoAP Header . . . . . . . . . . . . . . . . . . . . . . . 18
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 19 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 20
5.3. Additional Authenticated Data . . . . . . . . . . . . . . 21 5.3. Additional Authenticated Data . . . . . . . . . . . . . . 21
6. Sequence Numbers, Replay, Message Binding, and Freshness . . 22 6. Sequence Numbers, Replay, Message Binding, and Freshness . . 22
6.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 22 6.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 22
6.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 22 6.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 22
6.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 22
6.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 23 6.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 23
6.5. Losing Part of the Context State . . . . . . . . . . . . 23 6.5. Losing Part of the Context State . . . . . . . . . . . . 23
7. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Protecting the Request . . . . . . . . . . . . . . . . . 24 7.1. Protecting the Request . . . . . . . . . . . . . . . . . 25
7.2. Verifying the Request . . . . . . . . . . . . . . . . . . 25 7.2. Verifying the Request . . . . . . . . . . . . . . . . . . 25
7.3. Protecting the Response . . . . . . . . . . . . . . . . . 26 7.3. Protecting the Response . . . . . . . . . . . . . . . . . 27
7.4. Verifying the Response . . . . . . . . . . . . . . . . . 27 7.4. Verifying the Response . . . . . . . . . . . . . . . . . 27
8. OSCORE Compression . . . . . . . . . . . . . . . . . . . . . 28 8. OSCORE Compression . . . . . . . . . . . . . . . . . . . . . 29
8.1. Encoding of the Object-Security Value . . . . . . . . . . 28 8.1. Encoding of the Object-Security Value . . . . . . . . . . 29
8.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 29 8.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 30
8.3. Context Hint . . . . . . . . . . . . . . . . . . . . . . 30 8.3. Context Hint . . . . . . . . . . . . . . . . . . . . . . 30
8.4. Compression Examples . . . . . . . . . . . . . . . . . . 30 8.4. Examples of Compressed COSE Objects . . . . . . . . . . . 30
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. Proxy Operations . . . . . . . . . . . . . . . . . . . . . . 32 10. Proxy Operations . . . . . . . . . . . . . . . . . . . . . . 33
10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 33 10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 33
10.2. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 33 10.2. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 33
10.3. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 34 10.3. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 35
11. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. Security Considerations . . . . . . . . . . . . . . . . . . . 36
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38 13.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 38
13.2. Header Field Registrations . . . . . . . . . . . . . . . 38 13.2. Header Field Registrations . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . 38 15.1. Normative References . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 41 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 41 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 41
B.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 41 B.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 42
B.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 42 B.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) is a web application The Constrained Application Protocol (CoAP) is a web application
protocol, designed for constrained nodes and networks [RFC7228]. protocol, designed for constrained nodes and networks [RFC7228].
CoAP specifies the use of proxies for scalability and efficiency, and CoAP specifies the use of proxies for scalability and efficiency, and
a mapping to HTTP is also specified [RFC8075]. CoAP [RFC7252] a mapping to HTTP is also specified [RFC8075]. CoAP [RFC7252]
references DTLS [RFC6347] for security. CoAP and HTTP proxies references DTLS [RFC6347] for security. CoAP and HTTP proxies
require (D)TLS to be terminated at the proxy. The proxy therefore require (D)TLS to be terminated at the proxy. The proxy therefore
skipping to change at page 3, line 42 skipping to change at page 3, line 42
Environments (OSCORE) security protocol, protecting CoAP and CoAP- Environments (OSCORE) security protocol, protecting CoAP and CoAP-
mappable HTTP requests and responses end-to-end across intermediary mappable HTTP requests and responses end-to-end across intermediary
nodes such as CoAP forward proxies and cross-protocol translators nodes such as CoAP forward proxies and cross-protocol translators
including HTTP-to-CoAP proxies [RFC8075]. In addition to the core including HTTP-to-CoAP proxies [RFC8075]. In addition to the core
CoAP features defined in [RFC7252], OSCORE supports Observe [RFC7641] CoAP features defined in [RFC7252], OSCORE supports Observe [RFC7641]
and Blockwise [RFC7959]. An analysis of end-to-end security for CoAP and Blockwise [RFC7959]. An analysis of end-to-end security for CoAP
messages through some types of intermediary nodes is performed in messages through some types of intermediary nodes is performed in
[I-D.hartke-core-e2e-security-reqs]. OSCORE protects the Request/ [I-D.hartke-core-e2e-security-reqs]. OSCORE protects the Request/
Response layer only, and not the CoAP Messaging Layer (Section 2 of Response layer only, and not the CoAP Messaging Layer (Section 2 of
[RFC7252]). Therefore, all the CoAP messages mentioned in this [RFC7252]). Therefore, all the CoAP messages mentioned in this
document refer to non-empty CON, NON, and ACK messages. document refer to non-Empty CON, NON, and ACK messages [RFC7252].
Additionally, since the message formats for CoAP over unreliable Additionally, since the message formats for CoAP over unreliable
transport [RFC7252] and for CoAP over reliable transport transport [RFC7252] and for CoAP over reliable transport
[I-D.ietf-core-coap-tcp-tls] differ only in terms of Messaging Layer, [I-D.ietf-core-coap-tcp-tls] differ only in terms of Messaging Layer,
OSCORE can be applied to both unreliable and reliable transports. OSCORE can be applied to both unreliable and reliable transports.
OSCORE is designed for constrained nodes and networks and provides an OSCORE is designed for constrained nodes and networks and provides an
in-layer security protocol that does not depend on underlying layers. in-layer security protocol that does not depend on underlying layers.
OSCORE can be used anywhere where CoAP or HTTP can be used, including OSCORE can be used anywhere where CoAP or HTTP can be used, including
non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]). An non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]). An
extension of OSCORE may also be used to protect group communication extension of OSCORE may also be used to protect group communication
skipping to change at page 4, line 25 skipping to change at page 4, line 25
Section 10.2. OSCORE is designed to protect as much information as Section 10.2. OSCORE is designed to protect as much information as
possible, while still allowing proxy operations (Section 10). OSCORE possible, while still allowing proxy operations (Section 10). OSCORE
provides protection of message payload, almost all CoAP options, and provides protection of message payload, almost all CoAP options, and
the RESTful method. The solution transforms a message into an the RESTful method. The solution transforms a message into an
"OSCORE message" before sending, and vice versa after receiving. The "OSCORE message" before sending, and vice versa after receiving. The
OSCORE message is related to the original message in the following OSCORE message is related to the original message in the following
way: the original message is translated to CoAP (if not already in way: the original message is translated to CoAP (if not already in
CoAP) and the resulting message payload (if present), options not CoAP) and the resulting message payload (if present), options not
processed by a proxy, and the request/response method (CoAP Code) are processed by a proxy, and the request/response method (CoAP Code) are
protected in a COSE object. The message fields of the original protected in a COSE object. The message fields of the original
messages that are encrypted are not present in the OSCORE message, message that are encrypted are transported in the payload of the
and instead the Object-Security option/header and the compressed COSE OSCORE message, and the Object-Security option is included, see
object are included, see Figure 1. Figure 1.
Client Server Client Server
| OSCORE request - POST example.com: | | OSCORE request - POST example.com: |
| Header, Token, | | Header, Token, |
| Options: {Object-Security, ...}, | | Options: {Object-Security, ...}, |
| Payload: Compressed COSE object | | Payload: COSE ciphertext |
+--------------------------------------------->| +--------------------------------------------->|
| |
|<---------------------------------------------+
| OSCORE response - 2.04 (Changed): | | OSCORE response - 2.04 (Changed): |
| Header, Token, | | Header, Token, |
| Options: {Object-Security, ...}, | | Options: {Object-Security, ...}, |
| Payload: Compressed COSE object | | Payload: COSE ciphertext |
|<---------------------------------------------+
| | | |
Figure 1: Sketch of OSCORE with CoAP Figure 1: Sketch of CoAP with OSCORE
OSCORE may be used in very constrained settings, thanks to its small OSCORE may be used in very constrained settings, thanks to its small
message size and the restricted code and memory requirements in message size and the restricted code and memory requirements in
addition to what is required by CoAP. OSCORE can be combined with addition to what is required by CoAP. OSCORE can be combined with
transport layer security such as DTLS or TLS, thereby enabling end- transport layer security such as DTLS or TLS, thereby enabling end-
to-end security of e.g. CoAP Payload, Options and Code, in to-end security of e.g. CoAP Payload, Options and Code, in
combination with hop-by-hop protection of the Messaging Layer, during combination with hop-by-hop protection of the Messaging Layer, during
transport between end-point and intermediary node. Examples of the transport between end-point and intermediary node. Examples of the
use of OSCORE are given in Appendix B. use of OSCORE are given in Appendix B.
skipping to change at page 5, line 38 skipping to change at page 5, line 40
ID/Key, Recipient ID/Key, and Common IV are defined in Section 3.1. ID/Key, Recipient ID/Key, and Common IV are defined in Section 3.1.
2. The CoAP Object-Security Option 2. The CoAP Object-Security Option
The CoAP Object-Security option (see Figure 2) indicates that the The CoAP Object-Security option (see Figure 2) indicates that the
CoAP message is an OSCORE message and that it contains a compressed CoAP message is an OSCORE message and that it contains a compressed
COSE object (see Section 5 and Section 8). The Object-Security COSE object (see Section 5 and Section 8). The Object-Security
option is critical, safe to forward, part of the cache key, and not option is critical, safe to forward, part of the cache key, and not
repeatable. repeatable.
+-----+---+---+---+---+-----------------+-----------+--------+---------+ +-----+---+---+---+---+-----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default | | No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+-----------------+-----------+--------+---------+ +-----+---+---+---+---+-----------------+--------+--------+---------+
| TBD | x | | | | Object-Security | see below | 0-255 | (none) | | TBD | x | | | | Object-Security | (*) | 0-255 | (none) |
+-----+---+---+---+---+-----------------+-----------+--------+---------+ +-----+---+---+---+---+-----------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
(*) See below.
Figure 2: The Object-Security Option Figure 2: The Object-Security Option
The Object-Security option contains the OSCORE flag byte and for The Object-Security option contains the OSCORE flag byte (Section 8),
requests, the Sender ID (see Section 8). If the flag byte is all the Sender Sequence Number and the Sender ID when present
zero (0x00) the Option value SHALL be empty (Option Length = 0). An (Section 3). The detailed format is specified in Section 8). If the
endpoint receiving a CoAP message without payload, that also contains OSCORE flag byte is all zero (0x00) the Option value SHALL be empty
an Object-Security option SHALL treat it as malformed and reject it. (Option Length = 0). An endpoint receiving a CoAP message without
payload, that also contains an Object-Security option SHALL treat it
as malformed and reject it.
A successful response to a request with the Object-Security option A successful response to a request with the Object-Security option
SHALL contain the Object-Security option. Whether error responses SHALL contain the Object-Security option. Whether error responses
contain the Object-Security option depends on the error type (see contain the Object-Security option depends on the error type (see
Section 7). Section 7).
Since the payload and most options are encrypted Section 4, and the Since the payload and most options are encrypted Section 4, and the
corresponding plain text message fields of the original are not corresponding plain text message fields of the original are not
included in the OSCORE message, the processing of these fields does included in the OSCORE message, the processing of these fields does
not expand the total message size. not expand the total message size.
skipping to change at page 7, line 51 skipping to change at page 8, line 11
o Master Salt (OPTIONAL). Variable length byte string containing o Master Salt (OPTIONAL). Variable length byte string containing
the salt used to derive traffic keys and IVs. Its value is the salt used to derive traffic keys and IVs. Its value is
immutable once the security context is established. immutable once the security context is established.
o Common IV. Byte string derived from Master Secret and Master o Common IV. Byte string derived from Master Secret and Master
Salt. Length is determined by the AEAD Algorithm. Its value is Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established. immutable once the security context is established.
The Sender Context contains the following parameters: The Sender Context contains the following parameters:
o Sender ID. Non-negative integer used to identify the Sender o Sender ID. Byte string used to identify the Sender Context and to
Context and to assure unique nonces. Length is determined by the assure unique nonces. Maximum length is determined by the AEAD
AEAD Algorithm. Its value is immutable once the security context Algorithm. Its value is immutable once the security context is
is established. established.
o Sender Key. Byte string containing the symmetric key to protect o Sender Key. Byte string containing the symmetric key to protect
messages to send. Derived from Common Context and Sender ID. messages to send. Derived from Common Context and Sender ID.
Length is determined by the AEAD Algorithm. Its value is Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established. immutable once the security context is established.
o Sender Sequence Number. Non-negative integer used by the sender o Sender Sequence Number. Non-negative integer used by the sender
to protect requests and Observe notifications. Used as "Partial to protect requests and Observe notifications. Used as "Partial
IV" [RFC8152] to generate unique nonces for the AEAD. Maximum IV" [RFC8152] to generate unique nonces for the AEAD. Maximum
value is determined by the AEAD Algorithm. value is determined by the AEAD Algorithm.
The Recipient Context contains the following parameters: The Recipient Context contains the following parameters:
o Recipient ID. Non-negative integer used to identify the Recipient o Recipient ID. Byte string used to identify the Recipient Context
Context and to assure unique nonces. Length is determined by the and to assure unique nonces. Maximum length is determined by the
AEAD Algorithm. Its value is immutable once the security context AEAD Algorithm. Its value is immutable once the security context
is established. is established.
o Recipient Key. Byte string containing the symmetric key to verify o Recipient Key. Byte string containing the symmetric key to verify
messages received. Derived from Common Context and Recipient ID. messages received. Derived from Common Context and Recipient ID.
Length is determined by the AEAD Algorithm. Its value is Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established. immutable once the security context is established.
o Replay Window (Server only). The replay window to verify requests o Replay Window (Server only). The replay window to verify requests
received. received.
An endpoint may free up memory by not storing the Common IV, Sender An endpoint may free up memory by not storing the Common IV, Sender
Key, and Recipient Key, deriving them from the Master Key and Master Key, and Recipient Key, deriving them from the Master Key and Master
Salt when needed. Alternatively, an endpoint may free up memory by Salt when needed. Alternatively, an endpoint may free up memory by
not storing the Master Secret and Master Salt after the other not storing the Master Secret and Master Salt after the other
parameters have been derived. parameters have been derived.
The endpoints MAY interchange the client and server roles while Endpoints MAY operate in either or both roles as client and server
maintaining the same security context. When this happens, the former and use the same security context for those roles. Indpendent of
server still protects messages to send using its Sender Context, and being client or server, the endpoint protects messages to send using
verifies messages received using its Recipient Context. The same is its Sender Context, and verifies messages received using its
also true for the former client. The endpoints MUST NOT change the Recipient Context. The endpoints MUST NOT change the Sender/
Sender/Recipient ID when changing roles. In other words, changing Recipient ID when changing roles. In other words, changing the roles
the roles does not change the set of keys to be used. does not change the set of keys to be used.
3.2. Establishment of Security Context Parameters 3.2. Establishment of Security Context Parameters
The parameters in the security context are derived from a small set The parameters in the security context are derived from a small set
of input parameters. The following input parameters SHALL be pre- of input parameters. The following input parameters SHALL be pre-
established: established:
o Master Secret o Master Secret
o Sender ID o Sender ID
skipping to change at page 10, line 13 skipping to change at page 10, line 26
where: where:
o salt is the Master Salt as defined above o salt is the Master Salt as defined above
o IKM is the Master Secret is defined above o IKM is the Master Secret is defined above
o info is a CBOR array consisting of: o info is a CBOR array consisting of:
info = [ info = [
id : bstr / nil, id : bstr / nil,
alg : int, alg : int / tstr,
type : tstr, type : tstr,
L : uint L : uint
] ]
where: where:
o id is the Sender ID or Recipient ID when deriving keys and nil o id is the Sender ID or Recipient ID when deriving keys and nil
when deriving the Common IV. Sender ID and Recipient ID are when deriving the Common IV. The encoding is described in
encoded as described in Section 5 Section 5
o type is "Key" or "IV" o type is "Key" or "IV"
o L is the size of the key/IV for the AEAD algorithm used, in octets o L is the size of the key/IV for the AEAD algorithm used, in octets
For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in
[RFC8152]) is used, the value for L is 16 for keys and 13 for the [RFC8152]) is used, the value for L is 16 for keys and 13 for the
Common IV. Common IV.
3.2.2. Initial Sequence Numbers and Replay Window 3.2.2. Initial Sequence Numbers and Replay Window
skipping to change at page 10, line 48 skipping to change at page 11, line 13
Section 4.1.2.6 of [RFC6347]. Section 4.1.2.6 of [RFC6347].
3.3. Requirements on the Security Context Parameters 3.3. Requirements on the Security Context Parameters
As collisions may lead to the loss of both confidentiality and As collisions may lead to the loss of both confidentiality and
integrity, Sender ID SHALL be unique in the set of all security integrity, Sender ID SHALL be unique in the set of all security
contexts using the same Master Secret and Master Salt. When a contexts using the same Master Secret and Master Salt. When a
trusted third party assigns identifiers (e.g., using trusted third party assigns identifiers (e.g., using
[I-D.ietf-ace-oauth-authz]) or by using a protocol that allows the [I-D.ietf-ace-oauth-authz]) or by using a protocol that allows the
parties to negotiate locally unique identifiers in each endpoint, the parties to negotiate locally unique identifiers in each endpoint, the
Sender IDs can be very short. The maximum Sender ID is 2^(nonce Sender IDs can be very short. The maximum length of Sender ID is
length in bits - 40) - 1, For AES-CCM-16-64-128 the maximum Sender ID length of nonce - 6 bytes. For AES-CCM-16-64-128 the maximum length
is 2^64 - 1. If Sender ID uniqueness cannot be guaranteed, random of Sender ID is 7 bytes. If Sender ID uniqueness cannot be
Sender IDs MUST be used. Random Sender IDs MUST be long enough so guaranteed by construction, Sender IDs MUST be long uniformly random
that the probability of collisions is negligible. distributed byte strings such that the probability of collisions is
negligible.
To enable retrieval of the right Recipient Context, the Recipient ID To enable retrieval of the right Recipient Context, the Recipient ID
SHOULD be unique in the sets of all Recipient Contexts used by an SHOULD be unique in the sets of all Recipient Contexts used by an
endpoint. The Client MAY provide a Context Hint Section 8.3 to help endpoint. The Client MAY provide a Context Hint Section 8.3 to help
the Server find the right context. the Server find the right context.
While the triple (Master Secret, Master Salt, Sender ID) MUST be While the triple (Master Secret, Master Salt, Sender ID) MUST be
unique, the same Master Salt MAY be used with several Master Secrets unique, the same Master Salt MAY be used with several Master Secrets
and the same Master Secret MAY be used with several Master Salts. and the same Master Secret MAY be used with several Master Salts.
skipping to change at page 12, line 8 skipping to change at page 12, line 23
Class U message fields SHALL NOT be protected in transfer. Class I Class U message fields SHALL NOT be protected in transfer. Class I
and Class U message field values are transferred in the header or and Class U message field values are transferred in the header or
options part of the OSCORE message which is visible to proxies. options part of the OSCORE message which is visible to proxies.
Message fields not visible to proxies, i.e., transported in the Message fields not visible to proxies, i.e., transported in the
ciphertext of the COSE object, are called "Inner" (Class E). Message ciphertext of the COSE object, are called "Inner" (Class E). Message
fields transferred in the header or options part of the OSCORE fields transferred in the header or options part of the OSCORE
message, which is visible to proxies, are called "Outer" (Class I or message, which is visible to proxies, are called "Outer" (Class I or
U). U).
CoAP message fields are either Inner or Outer: Inner if the value is An OSCORE message may contain both an Inner and an Outer message
intended for the destination endpoint, Outer if the value is intended field of certain CoAP message fields. Inner if the value is intended
for a proxy. An OSCORE message may contain both an Inner and an for the destination endpoint, Outer if the value is intended for a
Outer message field of certain CoAP message fields. Inner and Outer proxy. Inner and Outer message fields are processed independently.
message fields are processed independently.
4.1. CoAP Payload 4.1. CoAP Payload
The CoAP Payload, if present in the original CoAP message, SHALL be The CoAP Payload, if present in the original CoAP message, SHALL be
encrypted and integrity protected and is thus an Inner message field. encrypted and integrity protected and is thus an Inner message field.
The sending endpoint writes the payload of the original CoAP message The sending endpoint writes the payload of the original CoAP message
into the plaintext (Section 5.2) input to the COSE object. The into the plaintext (Section 5.2) input to the COSE object. The
receiving endpoint verifies and decrypts the COSE object, and receiving endpoint verifies and decrypts the COSE object, and
recreates the payload of the original CoAP message. recreates the payload of the original CoAP message.
skipping to change at page 13, line 36 skipping to change at page 13, line 36
| 60 | Size1 | * | | * | | 60 | Size1 | * | | * |
+----+----------------+---+---+---+ +----+----------------+---+---+---+
E = Encrypt and Integrity Protect (Inner) E = Encrypt and Integrity Protect (Inner)
I = Integrity Protect only (Outer) I = Integrity Protect only (Outer)
U = Unprotected (Outer) U = Unprotected (Outer)
* = Special * = Special
Figure 4: Protection of CoAP Options Figure 4: Protection of CoAP Options
Unknown CoAP options SHALL be processed as class E (and no special Options that are unknown or for which OSCORE processing is not
processing). Specifications of new CoAP options SHOULD define how defined SHALL be processed as class E (and no special processing).
they are processed with OSCORE. A new COAP option SHOULD be of class Specifications of new CoAP options SHOULD define how they are
E unless it requires proxy processing. processed with OSCORE. A new COAP option SHOULD be of class E unless
it requires proxy processing. New CoAP options which are repeatable
and of class I MUST specify that proxies MUST NOT change the order of
the option's occurences.
4.2.1. Inner Options 4.2.1. Inner Options
When using OSCORE, Inner option message fields (marked in column E of When using OSCORE, Inner option message fields (marked in column E of
Figure 4) are sent in a way analogous to communicating in a protected Figure 4) are sent in a way analogous to communicating in a protected
manner directly with the other endpoint. manner directly with the other endpoint.
The sending endpoint SHALL write the Inner option message fields The sending endpoint SHALL write the Inner option message fields
present in the original CoAP message into the plaintext of the COSE present in the original CoAP message into the plaintext of the COSE
object Section 5.2, and then remove the Inner option message fields object Section 5.2, and then remove the Inner option message fields
skipping to change at page 18, line 16 skipping to change at page 18, line 20
a proxy. If the Observe option is removed from a CoAP request by a a proxy. If the Observe option is removed from a CoAP request by a
proxy, then the server can still verify the request (as a non-Observe proxy, then the server can still verify the request (as a non-Observe
request), and produce a non-Observe response. If the OSCORE client request), and produce a non-Observe response. If the OSCORE client
receives a response to an Observe request without an outer Observe receives a response to an Observe request without an outer Observe
value, then it MUST verify the response as a non-Observe response. value, then it MUST verify the response as a non-Observe response.
(The reverse case is covered in the verification of the response, see (The reverse case is covered in the verification of the response, see
Section 7.) Section 7.)
4.3. CoAP Header 4.3. CoAP Header
Most CoAP header fields are required to be read and/or changed by Most CoAP header fields (i.e. the message fields in the fixed 4-byte
CoAP proxies and thus cannot in general be protected end-to-end header) are required to be read and/or changed by CoAP proxies and
between the endpoints. As mentioned in Section 1, OSCORE protects thus cannot in general be protected end-to-end between the endpoints.
the CoAP Request/Response layer only, and not the Messaging Layer As mentioned in Section 1, OSCORE protects the CoAP Request/Response
(Section 2 of [RFC7252]), so fields such as Type and Message ID are layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
not protected with OSCORE. fields such as Type and Message ID are not protected with OSCORE.
The CoAP header field Code is protected by OSCORE. Code SHALL be The CoAP header field Code is protected by OSCORE. Code SHALL be
encrypted and integrity protected (Class E) to prevent an encrypted and integrity protected (Class E) to prevent an
intermediary from eavesdropping or manipulating the Code (e.g., intermediary from eavesdropping or manipulating the Code (e.g.,
changing from GET to DELETE). changing from GET to DELETE).
The sending endpoint SHALL write the Code of the original CoAP The sending endpoint SHALL write the Code of the original CoAP
message into the plaintext of the COSE object Section 5.2. After message into the plaintext of the COSE object Section 5.2. After
that, the Outer Code of the OSCORE message SHALL be set to 0.02 that, the Outer Code of the OSCORE message SHALL be set to 0.02
(POST) for requests and to 2.04 (Changed) for responses, except for (POST) for requests and to 2.04 (Changed) for responses, except for
skipping to change at page 19, line 32 skipping to change at page 19, line 32
The COSE Object SHALL be a COSE_Encrypt0 object with fields defined The COSE Object SHALL be a COSE_Encrypt0 object with fields defined
as follows as follows
o The "protected" field is empty. o The "protected" field is empty.
o The "unprotected" field includes: o The "unprotected" field includes:
* The "Partial IV" parameter. The value is set to the Sender * The "Partial IV" parameter. The value is set to the Sender
Sequence Number. All leading zeroes SHALL be removed when Sequence Number. All leading zeroes SHALL be removed when
encoding the Partial IV, i.e. the first byte (if any) SHALL encoding the Partial IV. The value 0 encodes to the byte
never be zero. This parameter SHALL be present in requests. string 0x00. This parameter SHALL be present in requests. In
In case of Observe (Section 4.2.3.4) the Partial IV SHALL be case of Observe (Section 4.2.3.4) the Partial IV SHALL be
present in responses, and otherwise the Partial IV SHALL NOT be present in responses, and otherwise the Partial IV SHOULD NOT
present in responses. be present in responses. (A non-Observe example where the
Partial IV is included in a response is provided in
Section 6.5.2.)
* The "kid" parameter. The value is set to the Sender ID (see * The "kid" parameter. The value is set to the Sender ID. This
Section 3). All leading zeroes SHALL be removed when encoding parameter SHALL be present in requests and SHOULD NOT be
the Partial IV, i.e. the first byte (if any) SHALL never be present in responses. (An example where the Sender ID is
zero. This parameter SHALL be present in requests and SHALL included in a response is the extension of OSCORE to group
NOT be present in responses. communication [I-D.tiloca-core-multicast-oscoap].)
o The "ciphertext" field is computed from the secret key (Sender Key o The "ciphertext" field is computed from the secret key (Sender Key
or Recipient Key), Nonce (see Section 5.1), Plaintext (see or Recipient Key), Nonce (see Section 5.1), Plaintext (see
Section 5.2), and the Additional Authenticated Data (AAD) (see Section 5.2), and the Additional Authenticated Data (AAD) (see
Section 5.3) following Section 5.2 of [RFC8152]. Section 5.3) following Section 5.2 of [RFC8152].
The encryption process is described in Section 5.3 of [RFC8152]. The encryption process is described in Section 5.3 of [RFC8152].
5.1. Nonce 5.1. Nonce
The nonce is constructed by left-padding the Partial IV (in network The nonce is constructed in the following way (see Figure 5):
byte order) with zeroes to exactly 5 bytes, left-padding the Sender
ID of the endpoint that generated the Partial IV (in network byte
order) with zeroes to exactly nonce length - 5 bytes, concatenating
the padded Partial IV with the padded ID, and then XORing with the
Common IV.
When observe is not used, the request and the response uses the same 1. left-padding the Partial IV (in network byte order) with zeroes
nonce. In this way, the Partial IV does not have to be sent in to exactly 5 bytes,
2. left-padding the (Sender) ID of the endpoint that generated the
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
3. concatenating the size of the ID (S) with the padded ID and the
padded Partial IV,
4. and then XORing with the Common IV.
Note that in this specification only algorithms that use nonces equal
or greater than 7 bytes are supported.
When observe is not used, the request and the response may use the
same nonce. In this way, the Partial IV does not have to be sent in
responses, which reduces the size. For processing instructions, see responses, which reduces the size. For processing instructions, see
Section 7. Section 7.
+--------------------------+--+--+--+--+--+ +---+-----------------------+--+--+--+--+--+
| ID of PIV generator | Partial IV |---+ | S | ID of PIV generator | Partial IV |----+
+--------------------------+--+--+--+--+--+ | +---+-----------------------+--+--+--+--+--+ |
| |
+-----------------------------------------+ | +------------------------------------------+ |
| Common IV |->(+) | Common IV |->(XOR)
+-----------------------------------------+ | +------------------------------------------+ |
| |
+-----------------------------------------+ | +------------------------------------------+ |
| Nonce |<--+ | Nonce |<---+
+-----------------------------------------+ +------------------------------------------+
Figure 5: AEAD Nonce Formation Figure 5: AEAD Nonce Formation
5.2. Plaintext 5.2. Plaintext
The Plaintext is formatted as a CoAP message without Header (see The Plaintext is formatted as a CoAP message without Header (see
Figure 6) consisting of: Figure 6) consisting of:
o the Code of the original CoAP message as defined in Section 3 of o the Code of the original CoAP message as defined in Section 3 of
[RFC7252]; and [RFC7252]; and
skipping to change at page 21, line 23 skipping to change at page 21, line 28
is payload) is payload)
Figure 6: Plaintext Figure 6: Plaintext
5.3. Additional Authenticated Data 5.3. Additional Authenticated Data
The external_aad SHALL be a CBOR array as defined below: The external_aad SHALL be a CBOR array as defined below:
external_aad = [ external_aad = [
version : uint, version : uint,
alg : int, alg : int / tstr,
request_kid : bstr, request_kid : bstr,
request_piv : bstr, request_piv : bstr,
options : bstr options : bstr
] ]
where: where:
o version: contains the OSCORE version number. Implementations of o version: contains the OSCORE version number. Implementations of
this specification MUST set this field to 1. Other values are this specification MUST set this field to 1. Other values are
reserved for future versions. reserved for future versions.
o alg: contains the AEAD Algorithm from the security context used o alg: contains the AEAD Algorithm from the security context used
for the exchange (see Section 3.1). for the exchange (see Section 3.1).
o request_kid: contains the value of the 'kid' in the COSE object of o request_kid: contains the value of the 'kid' in the COSE object of
the request (see Section 5). the request (see Section 5).
o request_piv: contains the value of the 'Partial IV' in the COSE o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5). object of the request (see Section 5).
o options: contains the (non-special) Class I options (see o options: contains the Class I options (see Section 4.2.2) present
Section 4.2.2) present in the original CoAP message encoded as in the original CoAP message encoded as described in Section 3.1
described in Section 3.1 of [RFC7252], where the delta is the of [RFC7252], where the delta is the difference to the previously
difference to the previously included class I option. included class I option.
NOTE: The format of the external_aad is for simplicity the same for
requests and responses, although some parameters, e.g. request_kid
need not be integrity protected in the requests.
6. Sequence Numbers, Replay, Message Binding, and Freshness 6. Sequence Numbers, Replay, Message Binding, and Freshness
6.1. Message Binding 6.1. Message Binding
In order to prevent response delay and mismatch attacks In order to prevent response delay and mismatch attacks
[I-D.mattsson-core-coap-actuators] from on-path attackers and [I-D.mattsson-core-coap-actuators] from on-path attackers and
compromised proxies, OSCORE binds responses to the request by compromised proxies, OSCORE binds responses to the requests by
including the request's ID (Sender ID or Recipient ID) and Partial IV including the kid and Partial IV of the request in the AAD of the
in the AAD of the response. The server therefore needs to store the response. The server therefore needs to store the kid and Partial IV
request's ID (Sender ID or Recipient ID) and Partial IV until all of the request until all responses have been sent.
responses have been sent.
6.2. AEAD Nonce Uniqueness 6.2. AEAD Nonce Uniqueness
An AEAD nonce MUST NOT be used more than once per AEAD key. In order An AEAD nonce MUST NOT be used more than once per AEAD key. In order
to assure unique nonces, each Sender Context contains a Sender to assure unique nonces, each Sender Context contains a Sender
Sequence Number used to protect requests, and - in case of Observe - Sequence Number used to protect requests, and - in case of Observe -
responses. If messages are processed concurrently, the operation of responses. If messages are processed concurrently, the operation of
reading and increasing the Sender Sequence Number MUST be atomic. reading and increasing the Sender Sequence Number MUST be atomic.
The maximum Sender Sequence Number is algorithm dependent, see The maximum Sender Sequence Number is algorithm dependent, see
Section 11. If the Sender Sequence Number exceeds the maximum, the Section 11, and no greater than 2^40 - 1. If the Sender Sequence
endpoint MUST NOT process any more messages with the given Sender Number exceeds the maximum, the endpoint MUST NOT process any more
Context. The endpoint SHOULD acquire a new security context (and messages with the given Sender Context. The endpoint SHOULD acquire
consequently inform the other endpoint) before this happens. The a new security context (and consequently inform the other endpoint)
latter is out of scope of this document. before this happens. The latter is out of scope of this document.
6.3. Freshness 6.3. Freshness
For requests, OSCORE provides weak absolute freshness as the only For requests, OSCORE provides weak absolute freshness as the only
guarantee is that the request is not older than the security context. guarantee is that the request is not older than the security context.
For applications having stronger demands on request freshness (e.g., For applications having stronger demands on request freshness (e.g.,
control of actuators), OSCORE needs to be augmented with mechanisms control of actuators), OSCORE needs to be augmented with mechanisms
providing freshness [I-D.amsuess-core-repeat-request-tag]. providing freshness [I-D.amsuess-core-repeat-request-tag].
For responses, the message binding guarantees that a response is not For responses, the message binding guarantees that a response is not
skipping to change at page 24, line 26 skipping to change at page 24, line 31
Storing to persistent memory can be costly. The value K gives a Storing to persistent memory can be costly. The value K gives a
trade-off between the number of storage operations and efficient trade-off between the number of storage operations and efficient
use of Sender Sequence Numbers. use of Sender Sequence Numbers.
6.5.2. Replay Window 6.5.2. Replay Window
To prevent accepting replay of previously received requests, the To prevent accepting replay of previously received requests, the
server MAY perform the following procedure after boot: server MAY perform the following procedure after boot:
o For each stored security context, the first time after boot the o For each stored security context, the first time after boot the
server receives an OSCORE request, the server uses the Repeat server receives an OSCORE request, the server responds with the
option [I-D.amsuess-core-repeat-request-tag] to get a request with Repeat option [I-D.amsuess-core-repeat-request-tag] to get a
verifiable freshness and uses that to synchronize the replay request with verifiable freshness. The server MUST use its
window. If the server can verify the fresh request, the Partial Partial IV when generating the nonce and MUST include the Partial
IV in the fresh request is set as the lower limit of the replay IV in the response.
window.
If the server using the Repeat option can verify a second request as
fresh, then the Partial IV of the second request is set as the lower
limit of the replay window.
6.5.3. Replay Protection of Observe Notifications 6.5.3. Replay Protection of Observe Notifications
To prevent accepting replay of previously received notification To prevent accepting replay of previously received notification
responses, the client MAY perform the following procedure after boot: responses, the client MAY perform the following procedure after boot:
o The client rejects notifications bound to the earlier o The client rejects notifications bound to the earlier
registration, removes all Notification Numbers and re-register registration, removes all Notification Numbers and re-register
using Observe. using Observe.
skipping to change at page 25, line 9 skipping to change at page 25, line 20
Given a CoAP request, the client SHALL perform the following steps to Given a CoAP request, the client SHALL perform the following steps to
create an OSCORE request: create an OSCORE request:
1. Retrieve the Sender Context associated with the target resource. 1. Retrieve the Sender Context associated with the target resource.
2. Compose the Additional Authenticated Data, as described in 2. Compose the Additional Authenticated Data, as described in
Section 5. Section 5.
3. Compute the AEAD nonce from the Sender ID, Common IV, and Partial 3. Compute the AEAD nonce from the Sender ID, Common IV, and Partial
IV (Sender Sequence Number in network byte order). Then (in one IV (Sender Sequence Number in network byte order) as described in
atomic operation, see Section 6.2) increment the Sender Sequence Section 5.1. Then (in one atomic operation, see Section 6.2)
Number by one. increment the Sender Sequence Number by one.
4. Encrypt the COSE object using the Sender Key. Compress the COSE 4. Encrypt the COSE object using the Sender Key. Compress the COSE
Object as specified in Section 8. Object as specified in Section 8.
5. Format the OSCORE message according to Section 4. The Object- 5. Format the OSCORE message according to Section 4. The Object-
Security option is added, see Section 4.2.2. Security option is added, see Section 4.2.2.
6. Store the association Token - Security Context. The client SHALL 6. Store the association Token - Security Context. The client SHALL
be able to find the Recipient Context from the Token in the be able to find the Recipient Context from the Token in the
response. response.
skipping to change at page 27, line 7 skipping to change at page 27, line 22
sent as simple CoAP responses, without OSCORE processing. sent as simple CoAP responses, without OSCORE processing.
1. Retrieve the Sender Context in the Security Context used to 1. Retrieve the Sender Context in the Security Context used to
verify the request. verify the request.
2. Compose the Additional Authenticated Data, as described in 2. Compose the Additional Authenticated Data, as described in
Section 5. Section 5.
3. Compute the AEAD nonce 3. Compute the AEAD nonce
* If Observe is not used, the nonce from the request is used.
* If Observe is used, Compute the AEAD nonce from the Sender ID, * If Observe is used, Compute the AEAD nonce from the Sender ID,
Common IV, and Partial IV (Sender Sequence Number in network Common IV, and Partial IV (Sender Sequence Number in network
byte order). Then (in one atomic operation, see Section 6.2) byte order). Then (in one atomic operation, see Section 6.2)
increment the Sender Sequence Number by one. increment the Sender Sequence Number by one.
* If Observe is not used, either the nonce from the request is
used or a new Partial IV is used.
4. Encrypt the COSE object using the Sender Key. Compress the COSE 4. Encrypt the COSE object using the Sender Key. Compress the COSE
Object as specified in Section 8. Object as specified in Section 8. If in 3. the nonce was
constructed from a new Partial IV, this Partial IV MUST be
included in the message. If the nonce from the request was used,
the Partial IV MUST NOT be included in the message.
5. Format the OSCORE message according to Section 4. The Object- 5. Format the OSCORE message according to Section 4. The Object-
Security option is added, see Section 4.2.2. Security option is added, see Section 4.2.2.
7.4. Verifying the Response 7.4. Verifying the Response
A client receiving a response containing the Object-Security option A client receiving a response containing the Object-Security option
SHALL perform the following steps: SHALL perform the following steps:
1. Process outer Block options according to [RFC7959], until all 1. Process outer Block options according to [RFC7959], until all
skipping to change at page 27, line 48 skipping to change at page 28, line 20
4. For Observe notifications, verify the received 'Partial IV' 4. For Observe notifications, verify the received 'Partial IV'
parameter against the corresponding Notification Number as parameter against the corresponding Notification Number as
described in Section 6. If the client receives a notification described in Section 6. If the client receives a notification
for which no Observe request was sent, then go to 11. for which no Observe request was sent, then go to 11.
5. Compose the Additional Authenticated Data, as described in 5. Compose the Additional Authenticated Data, as described in
Section 5. Section 5.
6. Compute the AEAD nonce 6. Compute the AEAD nonce
* If the Observe option is not present in the response, the 1. If the Observe option and the Partial IV are not present in
nonce from the request is used. the response, the nonce from the request is used.
* If the Observe option is present in the response, compute the 2. If the Observe option is present in the response, and the
AEAD nonce from the Recipient ID, Common IV, and the 'Partial Partial IV is not present in the response, then go to 11.
IV' parameter, received in the COSE Object.
3. If the Partial IV is present in the response, compute the
AEAD nonce from the Recipient ID, Common IV, and the
'Partial IV' parameter, received in the COSE Object.
7. Decrypt the COSE object using the Recipient Key. 7. Decrypt the COSE object using the Recipient Key.
* If decryption fails, then go to 11. * If decryption fails, then go to 11.
* If decryption succeeds and Observe is used, update the * If decryption succeeds and Observe is used, update the
corresponding Notification Number, as described in Section 6. corresponding Notification Number, as described in Section 6.
8. For each decrypted option, check if the option is also present 8. For each decrypted option, check if the option is also present
as an Outer option: if it is, discard the Outer. For example: as an Outer option: if it is, discard the Outer. For example:
skipping to change at page 28, line 48 skipping to change at page 29, line 21
a large number of different stateless use cases, and is not fully a large number of different stateless use cases, and is not fully
optimized for use as a stateful security protocol, leading to a optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion. In this section, we define larger than necessary message expansion. In this section, we define
a simple stateless compression mechanism for OSCORE called the a simple stateless compression mechanism for OSCORE called the
"compressed COSE object", which significantly reduces the per-packet "compressed COSE object", which significantly reduces the per-packet
overhead. overhead.
8.1. Encoding of the Object-Security Value 8.1. Encoding of the Object-Security Value
The value of the Object-Security option SHALL contain the OSCORE flag The value of the Object-Security option SHALL contain the OSCORE flag
byte and the kid parameter as follows: byte, the Partial IV parameter, the Context Hint parameter (length
and value), and the kid parameter as follows:
0 1 2 3 0 1 2 3 4 5 6 7 <--------- n bytes ------------->
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+---------------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0|h|k| n | Partial IV (if any)
|0 0 0|h|k| n | kid (if any) ... +-+-+-+-+-+-+-+-+---------------------------------
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<-- 1 byte --> <------ s bytes ------>
+------------+-----------------------+------------------+
| s (if any) | Context Hint (if any) | kid (if any) ... |
+------------+-----------------------+------------------+
Figure 7: Object-Security Value Figure 7: Object-Security Value
o The first byte (= the OSCORE flag byte) encodes a set of flags and o The first byte (= the OSCORE flag byte) encodes a set of flags and
the length of the Partial IV parameter. the length of the Partial IV parameter.
* The three least significant bits, n, encode the Partial IV * The three least significant bits encode the Partial IV length
length + 1. If n = 0 then the Partial IV is not present in the n. If n = 0 then the Partial IV is not present in the
compressed COSE object. The value n = 7 is reserved. compressed COSE object. The values n = 6 and n = 7 is
reserved.
* The fourth least significant bit is the kid flag, k: it is set * The fourth least significant bit is the kid flag, k: it is set
to 1 if the kid is present in the compressed COSE object. to 1 if the kid is present in the compressed COSE object.
* The fifth least significant bit is the Context Hint flag, h: it * The fifth least significant bit is the Context Hint flag, h: it
is set to 1 if the compressed COSE object contains a Context is set to 1 if the compressed COSE object contains a Context
Hint, see Section 8.3. Hint, see Section 8.3.
* The sixth-eighth least significant bits are reserved and SHALL * The sixth-eighth least significant bits are reserved and SHALL
be set to zero when not in use. be set to zero when not in use.
o The remaining bytes encode the value of the kid, if the kid is o The following n bytes encode the value of the Partial IV, if the
present (k = 1)
The presence of Partial IV and kid in requests and responses is
specified in Section 5, and summarized in Figure 8.
+--------------------------+-----+-----+
| | k | n |
+--------------------------+-----+-----+
| Request | 1 | > 0 |
| Response without Observe | 0 | 0 |
| Response with Observe | 0 | > 0 |
+--------------------------+-----+-----+
Figure 8: Presence of data fields in OSCORE flag byte
8.2. Encoding of the OSCORE Payload
The payload of the OSCORE message SHALL be encoded as follows:
o The first n - 1 bytes encode the value of the Partial IV, if the
Partial IV is present (n > 0). Partial IV is present (n > 0).
o The following 1 byte encode the length of the Context Hint o The following 1 byte encode the length of the Context Hint
(Section 8.3), s, if the Context Hint flag is set (h = 1). (Section 8.3) s, if the Context Hint flag is set (h = 1).
o The following s bytes encode the Context Hint, if the Context Hint o The following s bytes encode the Context Hint, if the Context Hint
flag is set (h = 1). flag is set (h = 1).
o The remaining bytes encode the ciphertext. o The remaining bytes encode the value of the kid, if the kid is
present (k = 1)
Note that the kid MUST be the last field of the object-security
value, even in case reserved bits are used and additional fields are
added to it.
8.2. Encoding of the OSCORE Payload
The payload of the OSCORE message SHALL encode the ciphertext of the
COSE object.
8.3. Context Hint 8.3. Context Hint
For certain use cases, e.g. deployments where the same Recipient ID For certain use cases, e.g. deployments where the same Recipient ID
is used with multiple contexts, it is necessary or favorable for the is used with multiple contexts, it is necessary or favorable for the
sending endpoint to provide a Context Hint in order for the receiving client to provide a Context Hint in order for the server to retrieve
endpoint to retrieve the recipient context. The Context Hint is the Recipient Context. The Context Hint is implicitly integrity
implicitly integrity protected, as a manipulation leads to the wrong protected, as manipulation leads to the wrong or no context being
or no context being retrieved resulting in a verification error. retrieved resulting in a verification error, as described in
Section 7.2. This parameter MAY be present in requests and SHALL NOT
be present in responses.
Examples: Examples:
o If the sending endpoint has an identifier in some other namespace o If the client has an identifier in some other namespace which can
which can be used by the recipient endpoint to retrieve or be used by the server to retrieve or establish the security
establish the security context, then that identifier can be used context, then that identifier can be used as Context Hint.
as Context Hint.
o In case of a group communication scenario o In case of a group communication scenario
[I-D.tiloca-core-multicast-oscoap], if the recipient endpoint [I-D.tiloca-core-multicast-oscoap], if the server belongs to
belongs to multiple groups, involving the same endpoints, then a multiple groups, then a group identifier can be used as Context
group identifier can be used as Context Hint to enable the Hint to enable the server to find the right security context.
receiving endpoint to find the right group security context.
8.4. Compression Examples
This section provides examples of COSE Objects before and after 8.4. Examples of Compressed COSE Objects
OSCORE compression. 8.4.1. Example: Requests
8.4.1. Example: Request Request with kid = 25 and Partial IV = 5
Before compression: Before compression (24 bytes):
[ [
h'', h'',
{ 4:h'25', 6:h'05' }, { 4:h'25', 6:h'05' },
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
0x83 40 a2 04 41 25 06 41 05 4e ae a0 15 56 67 92 After compression (17 bytes):
4d ff 8a 24 e4 cb 35 b9 (24 bytes)
After compression:
Flag byte: 0b00001010 = 0x0a Flag byte: 0b00001001 = 0x09
Option Value: 0a 25 (2 bytes) Option Value: 09 05 25 (3 bytes)
Payload: 05 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (15 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
8.4.2. Example: Request 2 Request with kid = empty string and Partial IV = 0
Before compression: After compression (16 bytes):
[ Flag byte: 0b00001001 = 0x09
h'',
{ 4:h'00', 6:h'00' },
h'aea0155667924dff8a24e4cb35b9'
]
0x83 40 a2 04 41 00 06 41 00 4e ae a0 15 56 67 92 Option Value: 09 00 (2 bytes)
4d ff 8a 24 e4 cb 35 b9 (24 bytes)
After compression: Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
Flag byte: 0b00001001 = 0x09 Request with kid = empty string, Partial IV = 5, and Context Hint =
0x44616c656b
Option Value: 09 (1 bytes) After compression (22 bytes):
Flag byte: 0b00011001 = 0x19
Option Value: 19 05 01 44 61 6c 65 6b (8 bytes)
Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
8.4.3. Example: Response (without Observe) 8.4.2. Example: Response (without Observe)
Before compression: Before compression (18 bytes):
[ [
h'', h'',
{}, {},
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
0x83 40 a0 4e ae a0 15 56 67 92 4d ff 8a 24 e4 cb After compression (14 bytes):
35 b9 (18 bytes)
After compression:
Flag byte: 0b00000000 = 0x00 Flag byte: 0b00000000 = 0x00
Option Value: (0 bytes) Option Value: (0 bytes)
Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
8.4.4. Example: Response (with Observe) 8.4.3. Example: Response (with Observe)
Before compression: Before compression (21 bytes):
[ [
h'', h'',
{ 6:h'07' }, { 6:h'07' },
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
0x83 40 a1 06 41 07 4e ae a0 15 56 67 92 4d ff After compression (16 bytes):
8a 24 e4 cb 35 b9 (21 bytes)
After compression:
Flag byte: 0b00000010 = 0x02 Flag byte: 0b00000001 = 0x01
Option Value: 02 (1 bytes) Option Value: 01 07 (2 bytes)
Payload: 07 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (15 bytes) Payload: ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 (14 bytes)
9. Web Linking 9. Web Linking
The use of OSCORE MAY be indicated by a target attribute "osc" in a The use of OSCORE MAY be indicated by a target attribute "osc" in a
web link [RFC5988] to a resource. This attribute is a hint web link [RFC8288] to a resource. This attribute is a hint
indicating that the destination of that link is to be accessed using indicating that the destination of that link is to be accessed using
OSCORE. Note that this is simply a hint, it does not include any OSCORE. Note that this is simply a hint, it does not include any
security context material or any other information required to run security context material or any other information required to run
OSCORE. OSCORE.
A value MUST NOT be given for the "osc" attribute; any present value A value MUST NOT be given for the "osc" attribute; any present value
MUST be ignored by parsers. The "osc" attribute MUST NOT appear more MUST be ignored by parsers. The "osc" attribute MUST NOT appear more
than once in a given link-value; occurrences after the first MUST be than once in a given link-value; occurrences after the first MUST be
ignored by parsers. ignored by parsers.
skipping to change at page 34, line 7 skipping to change at page 34, line 12
payload is the OSCORE payload Section 8.2, also base64url-encoded payload is the OSCORE payload Section 8.2, also base64url-encoded
without padding. without padding.
Example: Example:
Mapping and notation here is based on "Simple Form" (Section 5.4.1.1 Mapping and notation here is based on "Simple Form" (Section 5.4.1.1
of [RFC8075]). of [RFC8075]).
[HTTP request -- Before object security processing] [HTTP request -- Before object security processing]
GET http://proxy.url/hc/?target_uri=coap://device.url/orders HTTP/1.1 GET http://proxy.url/hc/?target_uri=coap://server.url/orders HTTP/1.1
[HTTP request -- HTTP Client to Proxy] [HTTP request -- HTTP Client to Proxy]
POST http://proxy.url/hc/?target_uri=coap://device.url/ HTTP/1.1 POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
Object-Security: 0b 25 Object-Security: 0b 25
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- Proxy to CoAP Server] [CoAP request -- Proxy to CoAP Server]
POST coap://device.url/ POST coap://server.url/
Object-Security: 0b 25 Object-Security: 0b 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP response -- CoAP Server to Proxy] [CoAP response -- CoAP Server to Proxy]
2.04 Changed 2.04 Changed
Object-Security: [empty] Object-Security: [empty]
Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- Proxy to HTTP Client] [HTTP response -- Proxy to HTTP Client]
skipping to change at page 35, line 8 skipping to change at page 35, line 17
Section 10.1 of [RFC7252] describes the behavior of a CoAP-to-HTTP Section 10.1 of [RFC7252] describes the behavior of a CoAP-to-HTTP
proxy. RFC 8075 [RFC8075] does not cover this direction in any more proxy. RFC 8075 [RFC8075] does not cover this direction in any more
detail and so an example instantiation of Section 10.1 of [RFC7252] detail and so an example instantiation of Section 10.1 of [RFC7252]
is used below. is used below.
Example: Example:
[CoAP request -- Before object security processing] [CoAP request -- Before object security processing]
GET coap://proxy.url/ GET coap://proxy.url/
Proxy-Uri=http://device.url/orders Proxy-Uri=http://server.url/orders
[CoAP request -- CoAP Client to Proxy] [CoAP request -- CoAP Client to Proxy]
POST coap://proxy.url/ POST coap://proxy.url/
Proxy-Uri=http://device.url/ Proxy-Uri=http://server.url/
Object-Security: 0b 25 Object-Security: 0b 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- Proxy to HTTP Server] [HTTP request -- Proxy to HTTP Server]
POST http://device.url/ HTTP/1.1 POST http://server.url/ HTTP/1.1
Object-Security: 0b 25 Object-Security: 0b 25
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP response -- HTTP Server to Proxy] [HTTP response -- HTTP Server to Proxy]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Object-Security: [empty] Object-Security: [empty]
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- CoAP Server to Proxy] [CoAP response -- CoAP Server to Proxy]
skipping to change at page 36, line 44 skipping to change at page 37, line 4
defined that only messages with sequence number which are equal to defined that only messages with sequence number which are equal to
previous sequence number + 1 are accepted. The alternatives to previous sequence number + 1 are accepted. The alternatives to
sequence numbers have their issues: very constrained devices may not sequence numbers have their issues: very constrained devices may not
be able to support accurate time, or to generate and store large be able to support accurate time, or to generate and store large
numbers of random nonces. The requirement to change key at counter numbers of random nonces. The requirement to change key at counter
wrap is a complication, but it also forces the user of this wrap is a complication, but it also forces the user of this
specification to think about implementing key renewal. specification to think about implementing key renewal.
The maximum sender sequence number is dependent on the AEAD The maximum sender sequence number is dependent on the AEAD
algorithm. The maximum sender sequence number SHALL be 2^40 - 1, or algorithm. The maximum sender sequence number SHALL be 2^40 - 1, or
any algorithm specific lower limit. The compression mechanism any algorithm specific lower limit, after which a new security
(Section 8) assumes that the Partial IV is 40 bits or less. The context must be generated. The mechanism to build the nonce
mandatory-to-implement AEAD algorithm AES-CCM-16-64-128 is selected (Section 5.1) assumes that the nonce is at least 56 bit-long, and the
for compatibility with CCM*. Partial IV is at most 40 bit-long. The mandatory-to-implement AEAD
algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*.
The inner block options enable the sender to split large messages The inner block options enable the sender to split large messages
into OSCORE-protected blocks such that the receiving node can verify into OSCORE-protected blocks such that the receiving node can verify
blocks before having received the complete message. The outer block blocks before having received the complete message. The outer block
options allow for arbitrary proxy fragmentation operations that options allow for arbitrary proxy fragmentation operations that
cannot be verified by the endpoints, but can by policy be restricted cannot be verified by the endpoints, but can by policy be restricted
in size since the encrypted options allow for secure fragmentation of in size since the encrypted options allow for secure fragmentation of
very large messages. A maximum message size (above which the sending very large messages. A maximum message size (above which the sending
endpoint fragments the message and the receiving endpoint discards endpoint fragments the message and the receiving endpoint discards
the message, if complying to the policy) may be obtained as part of the message, if complying to the policy) may be obtained as part of
skipping to change at page 39, line 14 skipping to change at page 39, line 23
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
skipping to change at page 40, line 9 skipping to change at page 40, line 14
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
15.2. Informative References 15.2. Informative References
[I-D.bormann-6lo-coap-802-15-ie] [I-D.bormann-6lo-coap-802-15-ie]
Bormann, C., "Constrained Application Protocol (CoAP) over Bormann, C., "Constrained Application Protocol (CoAP) over
IEEE 802.15.4 Information Element for IETF", draft- IEEE 802.15.4 Information Element for IETF", draft-
bormann-6lo-coap-802-15-ie-00 (work in progress), April bormann-6lo-coap-802-15-ie-00 (work in progress), April
2016. 2016.
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
skipping to change at page 40, line 51 skipping to change at page 41, line 15
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., and F. Mattsson, J., Fornehed, J., Selander, G., and F.
Palombini, "Controlling Actuators with CoAP", draft- Palombini, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-02 (work in progress), mattsson-core-coap-actuators-02 (work in progress),
November 2016. November 2016.
[I-D.seitz-ace-oscoap-profile] [I-D.seitz-ace-oscoap-profile]
Seitz, L., Palombini, F., and M. Gunnarsson, "OSCOAP Seitz, L., Palombini, F., and M. Gunnarsson, "OSCOAP
profile of the Authentication and Authorization for profile of the Authentication and Authorization for
Constrained Environments Framework", draft-seitz-ace- Constrained Environments Framework", draft-seitz-ace-
oscoap-profile-04 (work in progress), July 2017. oscoap-profile-05 (work in progress), October 2017.
[I-D.tiloca-core-multicast-oscoap] [I-D.tiloca-core-multicast-oscoap]
Tiloca, M., Selander, G., and F. Palombini, "Secure group Tiloca, M., Selander, G., and F. Palombini, "Secure group
communication for CoAP", draft-tiloca-core-multicast- communication for CoAP", draft-tiloca-core-multicast-
oscoap-03 (work in progress), July 2017. oscoap-03 (work in progress), July 2017.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 41, line 39 skipping to change at page 41, line 51
Appendix A. Test Vectors Appendix A. Test Vectors
TODO: This section needs to be updated. TODO: This section needs to be updated.
Appendix B. Examples Appendix B. Examples
This section gives examples of OSCORE. The message exchanges are This section gives examples of OSCORE. The message exchanges are
made, based on the assumption that there is a security context made, based on the assumption that there is a security context
established between client and server. For simplicity, these established between client and server. For simplicity, these
examples only indicate the content of the messages without going into examples only indicate the content of the messages without going into
detail of the COSE message format. detail of the (compressed) COSE message format.
B.1. Secure Access to Sensor B.1. Secure Access to Sensor
This example targets the scenario in Section 3.1 of This example targets the scenario in Section 3.1 of
[I-D.hartke-core-e2e-security-reqs] and illustrates a client [I-D.hartke-core-e2e-security-reqs] and illustrates a client
requesting the alarm status from a server. requesting the alarm status from a server.
Client Proxy Server Client Proxy Server
| | | | | |
+------>| | Code: 0.02 (POST) +------>| | Code: 0.02 (POST)
| POST | | Token: 0x8c | POST | | Token: 0x8c
| | | Object-Security: [kid:5f] | | | Object-Security: [kid:5f,Partial IV:42]
| | | Payload: [Partial IV:42, | | | Payload: {Code:0.01,
| | | {Code:0.01, | | | Uri-Path:"alarm_status"}
| | | Uri-Path:"alarm_status"}]
| | | | | |
| +------>| Code: 0.02 (POST) | +------>| Code: 0.02 (POST)
| | POST | Token: 0x7b | | POST | Token: 0x7b
| | | Object-Security: [kid:5f] | | | Object-Security: [kid:5f,Partial IV:42]
| | | Payload: [Partial IV:42, | | | Payload: {Code:0.01,
| | | {Code:0.01, | | | Uri-Path:"alarm_status"}
| | | Uri-Path:"alarm_status"}]
| | | | | |
| |<------+ Code: 2.04 (Changed) | |<------+ Code: 2.04 (Changed)
| | 2.04 | Token: 0x7b | | 2.04 | Token: 0x7b
| | | Object-Security: - | | | Object-Security: -
| | | Payload: [{Code:2.05, "OFF"}] | | | Payload: {Code:2.05, "OFF"}
| | | | | |
|<------+ | Code: 2.04 (Changed) |<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c | 2.04 | | Token: 0x8c
| | | Object-Security: - | | | Object-Security: -
| | | Payload: [{Code:2.05, "OFF"}] | | | Payload: {Code:2.05, "OFF"}
| | | | | |
Figure 9: Secure Access to Sensor. Square brackets [ ... ] indicate Figure 8: Secure Access to Sensor. Square brackets [ ... ] indicate
a COSE object. Curly brackets { ... } indicate encrypted data. content of compressed COSE object. Curly brackets { ... } indicate
encrypted data.
The request/response Codes are encrypted by OSCORE and only dummy The request/response Codes are encrypted by OSCORE and only dummy
Codes (POST/Changed) are visible in the header of the OSCORE message. Codes (POST/Changed) are visible in the header of the OSCORE message.
The option Uri-Path ("alarm_status") and payload ("OFF") are The option Uri-Path ("alarm_status") and payload ("OFF") are
encrypted. encrypted.
The COSE header of the request contains an identifier (5f), The COSE header of the request contains an identifier (5f),
indicating which security context was used to protect the message and indicating which security context was used to protect the message and
a Partial IV (42). a Partial IV (42).
skipping to change at page 43, line 12 skipping to change at page 43, line 18
[I-D.hartke-core-e2e-security-reqs] and illustrates a client [I-D.hartke-core-e2e-security-reqs] and illustrates a client
requesting subscription to a blood sugar measurement resource (GET requesting subscription to a blood sugar measurement resource (GET
/glucose), first receiving the value 220 mg/dl and then a second /glucose), first receiving the value 220 mg/dl and then a second
value 180 mg/dl. value 180 mg/dl.
Client Proxy Server Client Proxy Server
| | | | | |
+------>| | Code: 0.05 (FETCH) +------>| | Code: 0.05 (FETCH)
| FETCH | | Token: 0x83 | FETCH | | Token: 0x83
| | | Observe: 0 | | | Observe: 0
| | | Object-Security: [kid:ca] | | | Object-Security: [kid:ca,Partial IV:15]
| | | Payload: [Partial IV:15, | | | Payload: {Code:0.01,
| | | {Code:0.01, | | | Uri-Path:"glucose"}
| | | Uri-Path:"glucose"}]
| | | | | |
| +------>| Code: 0.05 (FETCH) | +------>| Code: 0.05 (FETCH)
| | FETCH | Token: 0xbe | | FETCH | Token: 0xbe
| | | Observe: 0 | | | Observe: 0
| | | Object-Security: [kid:ca] | | | Object-Security: [kid:ca,Partial IV:15]
| | | Payload: [Partial IV:15, | | | Payload: {Code:0.01,
| | | {Code:0.01, | | | Uri-Path:"glucose"}
| | | Uri-Path:"glucose"}]
| | | | | |
| |<------+ Code: 2.05 (Content) | |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe | | 2.05 | Token: 0xbe
| | | Observe: 7 | | | Observe: 7
| | | Object-Security: - | | | Object-Security: [Partial IV:32]
| | | Payload: [Partial IV:32, | | | Payload: {Code:2.05,
| | | {Code:2.05, | | | Content-Format:0, "220"}
| | | Content-Format:0, "220"}]
| | | | | |
|<------+ | Code: 2.05 (Content) |<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83 | 2.05 | | Token: 0x83
| | | Observe: 7 | | | Observe: 7
| | | Object-Security: - | | | Object-Security: [Partial IV:32]
| | | Payload: [Partial IV:32, | | | Payload: {Code:2.05,
| | | {Code:2.05, | | | Content-Format:0, "220"}
| | | Content-Format:0, "220"}]
... ... ... ... ... ...
| | | | | |
| |<------+ Code: 2.05 (Content) | |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe | | 2.05 | Token: 0xbe
| | | Observe: 8 | | | Observe: 8
| | | Object-Security: - | | | Object-Security: [Partial IV:36]
| | | Payload: [Partial IV:36, | | | Payload: {Code:2.05,
| | | {Code:2.05, | | | Content-Format:0, "180"}
| | | Content-Format:0, "180"}]
| | | | | |
|<------+ | Code: 2.05 (Content) |<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83 | 2.05 | | Token: 0x83
| | | Observe: 8 | | | Observe: 8
| | | Object-Security: - | | | Object-Security: [Partial IV:36]
| | | Payload: [Partial IV:36, | | | Payload: {Code:2.05,
| | | {Code:2.05, | | | Content-Format:0, "180"}
| | | Content-Format:0, "180"}]
| | | | | |
Figure 10: Secure Subscribe to Sensor. Square brackets [ ... ] Figure 9: Secure Subscribe to Sensor. Square brackets [ ... ]
indicate a COSE object. Curly brackets { ... } indicate encrypted indicate content of compressed COSE header. Curly brackets { ... }
data. indicate encrypted data.
The request/response Codes are encrypted by OSCORE and only dummy The request/response Codes are encrypted by OSCORE and only dummy
Codes (FETCH/Content) are visible in the header of the OSCORE Codes (FETCH/Content) are visible in the header of the OSCORE
message. The options Content-Format (0) and the payload ("220" and message. The options Content-Format (0) and the payload ("220" and
"180"), are encrypted. "180"), are encrypted.
The COSE header of the request contains an identifier (ca), The COSE header of the request contains an identifier (ca),
indicating the security context used to protect the message and a indicating the security context used to protect the message and a
Partial IV (15). The COSE headers of the responses contains Partial Partial IV (15). The COSE headers of the responses contains Partial
IVs (32 and 36). IVs (32 and 36).
 End of changes. 102 change blocks. 
275 lines changed or deleted 287 lines changed or added

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