draft-ietf-core-object-security-10.txt   draft-ietf-core-object-security-11.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: September 15, 2018 Ericsson AB Expires: September 20, 2018 Ericsson AB
L. Seitz L. Seitz
RISE SICS RISE SICS
March 14, 2018 March 19, 2018
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-10 draft-ietf-core-object-security-11
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 protection Signing and Encryption (COSE). OSCORE provides end-to-end protection
between endpoints communicating using CoAP or CoAP-mappable HTTP. between endpoints communicating using CoAP or CoAP-mappable HTTP.
OSCORE is designed for constrained nodes and networks supporting a OSCORE is designed for constrained nodes and networks supporting a
range of proxy operations, including translation between different range of proxy operations, including translation between different
transport protocols. transport protocols.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2018. This Internet-Draft will expire on September 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. The CoAP Object-Security Option . . . . . . . . . . . . . . . 6 2. The CoAP Object-Security Option . . . . . . . . . . . . . . . 6
3. The Security Context . . . . . . . . . . . . . . . . . . . . 7 3. The Security Context . . . . . . . . . . . . . . . . . . . . 7
3.1. Security Context Definition . . . . . . . . . . . . . . . 7 3.1. Security Context Definition . . . . . . . . . . . . . . . 7
3.2. Establishment of Security Context Parameters . . . . . . 9 3.2. Establishment of Security Context Parameters . . . . . . 9
3.3. Requirements on the Security Context Parameters . . . . . 11 3.3. Requirements on the Security Context Parameters . . . . . 11
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 12 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 12
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 13 4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 13
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 20 4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 20
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 21 4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 21
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 21 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 25 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 25
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 26 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 26
6.1. Encoding of the Object-Security Value . . . . . . . . . . 26 6.1. Encoding of the Object-Security Value . . . . . . . . . . 26
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 27 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 28
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 28 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 28
7. Sequence Numbers, Replay, Message Binding, and Freshness . . 29 7. Sequence Numbers, Replay, Message Binding, and Freshness . . 30
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 29 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 30
7.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 29 7.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 30
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 31
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31
7.5. Losing Part of the Context State . . . . . . . . . . . . 31 7.5. Losing Part of the Context State . . . . . . . . . . . . 32
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 32 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 33
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 33 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 34
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 34 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 35
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 35 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 36
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Proxy and HTTP Operations . . . . . . . . . . . . . . . . . . 37 10. Proxy and HTTP Operations . . . . . . . . . . . . . . . . . . 37
10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 37 10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 38
10.2. HTTP Processing . . . . . . . . . . . . . . . . . . . . 37 10.2. HTTP Processing . . . . . . . . . . . . . . . . . . . . 38
10.3. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 39 10.3. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 40
10.4. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 40 10.4. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
11.1. End-to-end protection . . . . . . . . . . . . . . . . . 42 11.1. End-to-end protection . . . . . . . . . . . . . . . . . 43
11.2. Security Context Establishment . . . . . . . . . . . . . 43 11.2. Security Context Establishment . . . . . . . . . . . . . 44
11.3. Replay Protection . . . . . . . . . . . . . . . . . . . 43 11.3. Replay Protection . . . . . . . . . . . . . . . . . . . 44
11.4. Cryptographic Considerations . . . . . . . . . . . . . . 43 11.4. Cryptographic Considerations . . . . . . . . . . . . . . 44
11.5. Message Fragmentation . . . . . . . . . . . . . . . . . 44 11.5. Message Segmentation . . . . . . . . . . . . . . . . . . 45
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 44 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 45
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12.1. COSE Header Parameters Registry . . . . . . . . . . . . 45 12.1. COSE Header Parameters Registry . . . . . . . . . . . . 46
12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45 12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 46
12.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 46 12.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 46
12.4. Header Field Registrations . . . . . . . . . . . . . . . 46 12.4. Header Field Registrations . . . . . . . . . . . . . . . 46
12.5. Media Type Registrations . . . . . . . . . . . . . . . . 46 12.5. Media Type Registrations . . . . . . . . . . . . . . . . 47
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 12.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 49
13.1. Normative References . . . . . . . . . . . . . . . . . . 48 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
13.2. Informative References . . . . . . . . . . . . . . . . . 49 13.1. Normative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 51
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 51 Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 52
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 52 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 52
Appendix B. Deployment examples . . . . . . . . . . . . . . . . 54 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 53
B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 54 Appendix B. Deployment examples . . . . . . . . . . . . . . . . 55
B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 54 B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 55
B.3. Client Aliveness . . . . . . . . . . . . . . . . . . . . 55 B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 55
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 56 B.3. Client Aliveness . . . . . . . . . . . . . . . . . . . . 56
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 56 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 57
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 57 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 57
C.3. Test Vector 3: OSCORE Request, Client . . . . . . . . . . 58 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 58
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 59 C.3. Test Vector 3: OSCORE Request, Client . . . . . . . . . . 59
C.5. Test Vector 5: OSCORE Response, Server . . . . . . . . . 60 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 60
C.6. Test Vector 6: OSCORE Response with Partial IV, Server . 61 C.5. Test Vector 5: OSCORE Response, Server . . . . . . . . . 61
Appendix D. Security properties . . . . . . . . . . . . . . . . 63 C.6. Test Vector 6: OSCORE Response with Partial IV, Server . 62
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 63 Appendix D. Overview of Security Properties . . . . . . . . . . 64
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63 D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 D.2. Protected Message Fields . . . . . . . . . . . . . . . . 64
D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 65
D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 66
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 68
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a web The Constrained Application Protocol (CoAP) [RFC7252] is a web
application protocol, designed for constrained nodes and networks transfer protocol, designed for constrained nodes and networks
[RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the [RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the
use of proxies for scalability and efficiency and references DTLS use of proxies for scalability and efficiency and references DTLS
([RFC6347]) for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to- [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
HTTP proxies require (D)TLS to be terminated at the proxy. The proxy proxies require (D)TLS to be terminated at the proxy. The proxy
therefore not only has access to the data required for performing the therefore not only has access to the data required for performing the
intended proxy functionality, but is also able to eavesdrop on, or intended proxy functionality, but is also able to eavesdrop on, or
manipulate any part of, the message payload and metadata in transit manipulate any part of, the message payload and metadata in transit
between the endpoints. The proxy can also inject, delete, or reorder between the endpoints. The proxy can also inject, delete, or reorder
packets since they are no longer protected by (D)TLS. packets since they are no longer protected by (D)TLS.
This document defines the Object Security for Constrained RESTful This document defines the Object Security for Constrained RESTful
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 CoAP features defined in [RFC7252], OSCORE supports Observe
[RFC7641], Blockwise [RFC7959], No-Response [RFC7967], and PATCH and [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and
FETCH [RFC8132]. An analysis of end-to-end security for CoAP FETCH [RFC8132]. 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 essentially protects the [I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the
RESTful interactions; the request method, the requested resource, the RESTful interactions; the request method, the requested resource, the
message payload, etc. (see Section 4). OSCORE protects neither the message payload, etc. (see Section 4). OSCORE protects neither the
CoAP Messaging Layer nor the CoAP Token which may change between the CoAP Messaging Layer nor the CoAP Token which may change between the
endpoints, and those are therefore processed as defined in [RFC7252]. endpoints, and those are therefore processed as defined in [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 [RFC8323] transport [RFC7252] and for CoAP over reliable transport [RFC8323]
differ only in terms of CoAP Messaging Layer, OSCORE can be applied differ only in terms of CoAP Messaging Layer, OSCORE can be applied
skipping to change at page 4, line 47 skipping to change at page 4, line 50
Figure 1: Abstract Layering of CoAP with OSCORE Figure 1: Abstract Layering of CoAP with OSCORE
OSCORE works in very constrained nodes and networks, thanks to its OSCORE works in very constrained nodes and networks, thanks to its
small message size and the restricted code and memory requirements in small message size and the restricted code and memory requirements in
addition to what is required by CoAP. Examples of the use of OSCORE addition to what is required by CoAP. Examples of the use of OSCORE
are given in Appendix A. OSCORE does not depend on underlying are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used, layers, and 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]). including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
OSCORE may be used together with (D)TLS over one or more hops in the OSCORE may be used together with (D)TLS over one or more hops in the
end-to-end path, e.g. with HTTPs in one hop and with plain CoAP in end-to-end path, e.g. with HTTPS in one hop and with plain CoAP in
another hop. another hop.
The use of OSCORE does not affect the URI scheme and OSCORE can The use of OSCORE does not affect the URI scheme and OSCORE can
therefore be used with any URI scheme defined for CoAP or HTTP. The therefore be used with any URI scheme defined for CoAP or HTTP. The
application decides the conditions for which OSCORE is required. application decides the conditions for which OSCORE is required.
OSCORE uses pre-shared keys which may have been established out-of- OSCORE uses pre-shared keys which may have been established out-of-
band or with a key establishment protocol (see Section 3.2). The band or with a key establishment protocol (see Section 3.2). The
technical solution builds on CBOR Object Signing and Encryption technical solution builds on CBOR Object Signing and Encryption
(COSE) [RFC8152], providing end-to-end encryption, integrity, replay (COSE) [RFC8152], providing end-to-end encryption, integrity, replay
skipping to change at page 6, line 14 skipping to change at page 6, line 14
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in CoAP [RFC7252], Observe [RFC7641], Blockwise [RFC7959], described in CoAP [RFC7252], Observe [RFC7641], Block-wise [RFC7959],
COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl] as COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl] as
summarized in Appendix E, and constrained environments [RFC7228]. summarized in Appendix E, and constrained environments [RFC7228].
The term "hop" is used to denote a particular leg in the end-to-end The term "hop" is used to denote a particular leg in the end-to-end
path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or
"hop-by-hop fragmentation") opposed to "end-to-end", is used in this "hop-by-hop fragmentation") opposed to "end-to-end", is used in this
document to indicate that the messages are processed accordingly in document to indicate that the messages are processed accordingly in
the intermediaries, rather than just forwarded to the next node. the intermediaries, rather than just forwarded to the next node.
The term "stop processing" is used throughout the document to denote The term "stop processing" is used throughout the document to denote
skipping to change at page 7, line 17 skipping to change at page 7, line 17
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 8). Section 8).
A CoAP proxy SHOULD NOT cache a response to a request with an Object- A CoAP proxy SHOULD NOT cache a response to a request with an Object-
Security option, since the response is only applicable to the Security option, since the response is only applicable to the
original request (see Section 10.1). As the compressed COSE Object original request (see Section 10.1). As the compressed COSE Object
is included in the cache key, messages with the Object-Security is included in the cache key, messages with the Object-Security
option will never generate cache hits. For Max-Age processing (see option will never generate cache hits. For Max-Age processing, see
Section 4.1.3.1). Section 4.1.3.1.
3. The Security Context 3. The Security Context
OSCORE requires that client and server establish a shared security OSCORE requires that client and server establish a shared security
context used to process the COSE objects. OSCORE uses COSE with an context used to process the COSE objects. OSCORE uses COSE with an
Authenticated Encryption with Additional Data (AEAD, [RFC5116]) Authenticated Encryption with Additional Data (AEAD, [RFC5116])
algorithm for protecting message data between a client and a server. algorithm for protecting message data between a client and a server.
In this section, we define the security context and how it is derived In this section, we define the security context and how it is derived
in client and server based on a shared secret and a key derivation in client and server based on a shared secret and a key derivation
function (KDF). function (KDF).
skipping to change at page 10, line 23 skipping to change at page 10, line 23
* Default is the empty string * Default is the empty string
o Key Derivation Function (KDF) o Key Derivation Function (KDF)
* Default is HKDF SHA-256 * Default is HKDF SHA-256
o Replay Window Type and Size o Replay Window Type and Size
* Default is DTLS-type replay protection with a window size of 32 * Default is DTLS-type replay protection with a window size of 32
([RFC6347]) [RFC6347]
All input parameters need to be known to and agreed on by both All input parameters need to be known to and agreed on by both
endpoints, but the replay window may be different in the two endpoints, but the replay window may be different in the two
endpoints. How the input parameters are pre-established, is endpoints. The way the input parameters are pre-established, is
application specific. The OSCORE profile of the ACE framework may be application specific. The OSCORE profile of the ACE framework may be
used to establish the necessary input parameters used to establish the necessary input parameters
([I-D.ietf-ace-oscore-profile]), or a key exchange protocol such as [I-D.ietf-ace-oscore-profile], or a key exchange protocol for
the TLS/DTLS handshake ([I-D.mattsson-ace-tls-oscore]) or EDHOC providing forward secrecy. Other examples of deploying OSCORE are
([I-D.selander-ace-cose-ecdhe]) providing forward secrecy. Other given in Appendix B.
examples of deploying OSCORE are given in Appendix B.
3.2.1. Derivation of Sender Key, Recipient Key, and Common IV 3.2.1. Derivation of Sender Key, Recipient Key, and Common IV
The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms
defined in COSE. HKDF SHA-256 is mandatory to implement. The defined in COSE. HKDF SHA-256 is mandatory to implement. The
security context parameters Sender Key, Recipient Key, and Common IV security context parameters Sender Key, Recipient Key, and Common IV
SHALL be derived from the input parameters using the HKDF, which SHALL be derived from the input parameters using the HKDF, which
consists of the composition of the HKDF-Extract and HKDF-Expand steps consists of the composition of the HKDF-Extract and HKDF-Expand steps
([RFC5869]): [RFC5869]:
output parameter = HKDF(salt, IKM, info, L) output parameter = HKDF(salt, IKM, info, L)
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 as defined above o IKM is the Master Secret as defined above
o info is a CBOR array consisting of: o info is a CBOR array consisting of:
info = [ info = [
id : bstr, id : bstr,
alg_aead : int / tstr, alg_aead : int / tstr,
type : tstr, type : tstr,
L : uint L : uint
] ]
where: where:
skipping to change at page 11, line 48 skipping to change at page 11, line 47
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 length of Sender ID in Sender IDs can be very short. The maximum length of Sender ID in
bytes equals the length of AEAD nonce minus 6. For AES-CCM-16-64-128 bytes equals the length of AEAD nonce minus 6. For AES-CCM-16-64-128
the maximum length of Sender ID is 7 bytes. Sender IDs MAY be the maximum length of Sender ID is 7 bytes.
uniformly random distributed byte strings if the probability of
collisions is negligible.
If Sender ID uniqueness cannot be guaranteed by construction, Sender
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
To simplify retrieval of the right Recipient Context, the Recipient To simplify retrieval of the right Recipient Context, the Recipient
ID SHOULD be unique in the sets of all Recipient Contexts used by an ID SHOULD be unique in the sets of all Recipient Contexts used by an
endpoint. If an endpoint has the same Recipient ID with different endpoint. If an endpoint has the same Recipient ID with different
Recipient Contexts, i.e. the Recipient Contexts are derived from Recipient Contexts, i.e. the Recipient Contexts are derived from
different keying material, then the endpoint may need to try multiple different keying material, then the endpoint may need to try multiple
times before finding the right security context associated to the times before finding the right security context associated to the
Recipient ID. The Client MAY provide a 'kid context' parameter Recipient ID. The Client MAY provide a 'kid context' parameter
(Section 5.1) to help the Server find the right context. (Section 5.1) to help the Server find the right context.
skipping to change at page 13, line 23 skipping to change at page 13, line 16
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). There are currently no Class I options defined. U). There are currently no Class I options defined.
An OSCORE message may contain both an Inner and an Outer instance of An OSCORE message may contain both an Inner and an Outer instance of
a certain CoAP message field. Inner message fields are intended for a certain CoAP message field. Inner message fields are intended for
the receiving endpoint, whereas Outer message fields are used to the receiving endpoint, whereas Outer message fields are used to
support proxy operations. Inner and Outer message fields are enable proxy operations. Inner and Outer message fields are
processed independently. processed independently.
4.1. CoAP Options 4.1. CoAP Options
A summary of how options are protected is shown in Figure 5. Note A summary of how options are protected is shown in Figure 5. Note
that some options may have both Inner and Outer message fields which that some options may have both Inner and Outer message fields which
are protected accordingly. The options which require special are protected accordingly. The options which require special
processing are labelled with asterisks. processing are labelled with asterisks.
+-----+-----------------+---+---+ +-----+-----------------+---+---+
skipping to change at page 16, line 7 skipping to change at page 16, line 7
OSCORE error responses, which are described in Section 7.4, OSCORE error responses, which are described in Section 7.4,
Section 8.2 and Section 8.4. Such message field is then processed Section 8.2 and Section 8.4. Such message field is then processed
according to Section 4.1.2. according to Section 4.1.2.
Successful OSCORE responses do not need to include an Outer Max-Age Successful OSCORE responses do not need to include an Outer Max-Age
option since the responses are non-cacheable by construction (see option since the responses are non-cacheable by construction (see
Section 4.2). Section 4.2).
4.1.3.2. The Block Options 4.1.3.2. The Block Options
Blockwise [RFC7959] is an optional feature. An implementation MAY Block-wise [RFC7959] is an optional feature. An implementation MAY
support [RFC7252] and the Object-Security option without supporting support [RFC7252] and the Object-Security option without supporting
Blockwise. The Block options (Block1, Block2, Size1, Size2), when block-wise transfers. The Block options (Block1, Block2, Size1,
Inner message fields, provide secure message fragmentation such that Size2), when Inner message fields, provide secure message
each fragment can be verified. The Block options, when Outer message segmentation such that each segment can be verified. The Block
fields, enables hop-by-hop fragmentation of the OSCORE message. options, when Outer message fields, enables hop-by-hop fragmentation
Inner and Outer block processing may have different performance of the OSCORE message. Inner and Outer block processing may have
properties depending on the underlying transport. The end-to-end different performance properties depending on the underlying
integrity of the message can be verified both in case of Inner and transport. The end-to-end integrity of the message can be verified
Outer Blockwise provided all blocks are received. both in case of Inner and Outer Block-wise transfers provided all
blocks are received.
4.1.3.2.1. Inner Block Options 4.1.3.2.1. Inner Block Options
The sending CoAP endpoint MAY fragment a CoAP message as defined in The sending CoAP endpoint MAY fragment a CoAP message as defined in
[RFC7959] before the message is processed by OSCORE. In this case [RFC7959] before the message is processed by OSCORE. In this case
the Block options SHALL be processed by OSCORE as Inner options the Block options SHALL be processed by OSCORE as Inner options
(Section 4.1.1). The receiving CoAP endpoint SHALL process the (Section 4.1.1). The receiving CoAP endpoint SHALL process the
OSCORE message according to Section 4.1.1 before processing Blockwise OSCORE message according to Section 4.1.1 before processing Block-
as defined in [RFC7959]. wise as defined in [RFC7959].
4.1.3.2.2. Outer Block Options 4.1.3.2.2. Outer Block Options
Proxies MAY fragment an OSCORE message using [RFC7959], by Proxies MAY fragment an OSCORE message using [RFC7959], by
introducing Block option message fields that are Outer introducing Block option message fields that are Outer
(Section 4.1.2) and not generated by the sending endpoint. Note that (Section 4.1.2) and not generated by the sending endpoint. Note that
the Outer Block options are neither encrypted nor integrity the Outer Block options are neither encrypted nor integrity
protected. As a consequence, a proxy can maliciously inject block protected. As a consequence, a proxy can maliciously inject block
fragments indefinitely, since the receiving endpoint needs to receive fragments indefinitely, since the receiving endpoint needs to receive
the last block (see [RFC7959]) to be able to compose the OSCORE the last block (see [RFC7959]) to be able to compose the OSCORE
skipping to change at page 18, line 23 skipping to change at page 18, line 25
See Sections 6.1 and 12.6 of [RFC7252] for more information. See Sections 6.1 and 12.6 of [RFC7252] for more information.
4.1.3.4. Observe 4.1.3.4. Observe
Observe [RFC7641] is an optional feature. An implementation MAY Observe [RFC7641] is an optional feature. An implementation MAY
support [RFC7252] and the Object-Security option without supporting support [RFC7252] and the Object-Security option without supporting
[RFC7641]. The Observe option as used here targets the requirements [RFC7641]. The Observe option as used here targets the requirements
on forwarding of [I-D.hartke-core-e2e-security-reqs] (Section 2.2.1). on forwarding of [I-D.hartke-core-e2e-security-reqs] (Section 2.2.1).
In order for an OSCORE-unaware proxy to support forwarding of Observe In order for an OSCORE-unaware proxy to support forwarding of Observe
messages ([RFC7641]), there SHALL be an Outer Observe option, i.e., messages [RFC7641], there SHALL be an Outer Observe option, i.e.,
present in the options part of the OSCORE message. The processing of present in the options part of the OSCORE message. The processing of
the CoAP Code for Observe messages is described in Section 4.2. the CoAP Code for Observe messages is described in Section 4.2.
To secure the order of notifications, the client SHALL maintain a To secure the order of notifications, the client SHALL maintain a
Notification Number for each Observation it registers. The Notification Number for each Observation it registers. The
Notification Number is a non-negative integer containing the largest Notification Number is a non-negative integer containing the largest
Partial IV of the successfully received notifications for the Partial IV of the successfully received notifications for the
associated Observe registration (see Section 7.4). The Notification associated Observe registration (see Section 7.4). The Notification
Number is initialized to the Partial IV of the first successfully Number is initialized to the Partial IV of the first successfully
received notification response to the registration request. In received notification response to the registration request. In
skipping to change at page 20, line 38 skipping to change at page 20, line 38
Most CoAP Header fields (i.e. the message fields in the fixed 4-byte Most CoAP Header fields (i.e. the message fields in the fixed 4-byte
header) are required to be read and/or changed by CoAP proxies and header) are required to be read and/or changed by CoAP proxies and
thus cannot in general be protected end-to-end between the endpoints. thus cannot in general be protected end-to-end between the endpoints.
As mentioned in Section 1, OSCORE protects the CoAP Request/Response As mentioned in Section 1, OSCORE protects the CoAP Request/Response
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are 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 on 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 (see Section 5.3). message into the plaintext of the COSE object (see Section 5.3).
After that, the Outer Code of the OSCORE message SHALL be set to 0.02 After that, the Outer Code of the OSCORE message SHALL be set to 0.02
(POST) for requests without Observe option, to 0.05 (FETCH) for (POST) for requests without Observe option, to 0.05 (FETCH) for
requests with Observe option, and to 2.04 (Changed) for responses. requests with Observe option, and to 2.04 (Changed) for responses.
Using FETCH with Observe allows OSCORE to be compliant with the Using FETCH with Observe allows OSCORE to be compliant with the
Observe processing in OSCORE-unaware proxies. The choice of POST and Observe processing in OSCORE-unaware proxies. The choice of POST and
FETCH ([RFC8132]) allows all OSCORE messages to have payload. FETCH [RFC8132] allows all OSCORE messages to have payload.
The receiving endpoint SHALL discard the Code in the OSCORE message The receiving endpoint SHALL discard the Code in the OSCORE message
and write the Code of the plaintext in the COSE object (Section 5.3) and write the Code of the plaintext in the COSE object (Section 5.3)
into the decrypted CoAP message. into the decrypted CoAP message.
The other currently defined CoAP Header fields are Unprotected (Class The other currently defined CoAP Header fields are Unprotected (Class
U). The sending endpoint SHALL write all other header fields of the U). The sending endpoint SHALL write all other header fields of the
original message into the header of the OSCORE message. The original message into the header of the OSCORE message. The
receiving endpoint SHALL write the header fields from the received receiving endpoint SHALL write the header fields from the received
OSCORE message into the header of the decrypted CoAP message. OSCORE message into the header of the decrypted CoAP message.
skipping to change at page 21, line 22 skipping to change at page 21, line 22
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.3) input to the COSE object. The into the plaintext (Section 5.3) 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.
4.3. Signaling Messages 4.3. Signaling Messages
Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange
information related to an underlying transport connection in the information related to an underlying transport connection in the
specific case of CoAP over reliable transports ([RFC8323]). The use specific case of CoAP over reliable transports [RFC8323].
of OSCORE for protecting Signaling is application dependent.
OSCORE MAY be used to protect Signaling if the endpoints for OSCORE OSCORE MAY be used to protect Signaling if the endpoints for OSCORE
coincide with the endpoints for the connection. If OSCORE is used to coincide with the endpoints for the signaling message. If OSCORE is
protect Signaling then: used to protect Signaling then:
o To comply with [RFC8323], an initial empty CSM message SHALL be
sent. The subsequent signaling message SHALL be protected.
o Signaling messages SHALL be protected as CoAP Request messages, o Signaling messages SHALL be protected as CoAP Request messages,
except in the case the Signaling message is a response to a except in the case the Signaling message is a response to a
previous Signaling message, in which case it SHALL be protected as previous Signaling message, in which case it SHALL be protected as
a CoAP Response message. For example, 7.02 (Ping) is protected as a CoAP Response message. For example, 7.02 (Ping) is protected as
a CoAP Request and 7.03 (Pong) as a CoAP response. a CoAP Request and 7.03 (Pong) as a CoAP response.
o The Outer Code for Signaling messages SHALL be set to 0.02 (POST), o The Outer Code for Signaling messages SHALL be set to 0.02 (POST),
unless it is a response to a previous Signaling message, in which unless it is a response to a previous Signaling message, in which
case it SHALL be set to 2.04 (Changed). case it SHALL be set to 2.04 (Changed).
skipping to change at page 22, line 26 skipping to change at page 22, 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. The value 0 encodes to the byte encoding the Partial IV, except in the case of value 0 which is
string 0x00. This parameter SHALL be present in requests. In encoded to the byte string 0x00. This parameter SHALL be
case of Observe (Section 4.1.3.4) the Partial IV SHALL be present in requests. In case of Observe (Section 4.1.3.4) the
present in responses, and otherwise the Partial IV will not Partial IV SHALL be present in responses, and otherwise the
typically be present in responses. (A non-Observe example Partial IV will not typically be present in responses. (A non-
where the Partial IV is included in a response is provided in Observe example where the Partial IV is included in a response
Section 7.5.2.) is provided in Section 7.5.2.)
* The 'kid' parameter. The value is set to the Sender ID. This * The 'kid' parameter. The value is set to the Sender ID. This
parameter SHALL be present in requests and will not typically parameter SHALL be present in requests and will not typically
be present in responses. An example where the Sender ID is be present in responses. An example where the Sender ID is
included in a response is the extension of OSCORE to group included in a response is the extension of OSCORE to group
communication [I-D.ietf-core-oscore-groupcomm]. communication [I-D.ietf-core-oscore-groupcomm].
* Optionally, a 'kid context' parameter as defined in * Optionally, a 'kid context' parameter as defined in
Section 5.1. This parameter MAY be present in requests and Section 5.1. This parameter MAY be present in requests and
SHALL NOT be present in responses. SHALL NOT be present in responses.
skipping to change at page 25, line 41 skipping to change at page 25, line 47
request_piv : bstr, request_piv : bstr,
options : bstr options : bstr
] ]
where: where:
o oscore_version: contains the OSCORE version number. o oscore_version: contains the OSCORE version number.
Implementations of this specification MUST set this field to 1. Implementations of this specification MUST set this field to 1.
Other values are reserved for future versions. Other values are reserved for future versions.
o algorithms: contains (for extensibility) an array of algorithms,
according to this specification only containing alg_aead.
o alg_aead: contains the AEAD Algorithm from the security context o alg_aead: contains the AEAD Algorithm from the security context
used for the exchange (see Section 3.1). used 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 Class I options (see Section 4.1.2) present o options: contains the Class I options (see Section 4.1.2) present
skipping to change at page 28, line 7 skipping to change at page 28, line 17
section, and on the presence and length of the other parameters, as section, and on the presence and length of the other parameters, as
defined in the separate documents. defined in the separate documents.
6.2. Encoding of the OSCORE Payload 6.2. Encoding of the OSCORE Payload
The payload of the OSCORE message SHALL encode the ciphertext of the The payload of the OSCORE message SHALL encode the ciphertext of the
COSE object. COSE object.
6.3. Examples of Compressed COSE Objects 6.3. Examples of Compressed COSE Objects
This section covers a list of OSCORE Header Compression examples for
requests and responses. The examples assume the COSE_Encrypt0 object
is set (which means the CoAP message and cryptographic material is
known). Note that the full CoAP unprotected message, as well as the
full security context, is not reported in the examples, but only the
input necessary to the compression mechanism, i.e. the COSE_Encrypt0
object. The output is the compressed COSE object as defined in
Section 6, divided into two parts, since the object is transported in
two CoAP fields: Object-Security option value and CoAP payload.
6.3.1. Examples: Requests 6.3.1. Examples: Requests
1. Request with kid = 0x25 and Partial IV = 0x05 1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
0x25 and Partial IV = 0x05
Before compression (24 bytes): Before compression (24 bytes):
[ [
h'', h'',
{ 4:h'25', 6:h'05' }, { 4:h'25', 6:h'05' },
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
After compression (17 bytes): After compression (17 bytes):
Flag byte: 0b00001001 = 0x09 Flag byte: 0b00001001 = 0x09
Option Value: 09 05 25 (3 bytes) Option Value: 09 05 25 (3 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)
2. Request with kid = empty string and Partial IV = 0x00 2. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
empty string and Partial IV = 0x00
Before compression (23 bytes):
[
h'',
{ 4:h'', 6:h'00' },
h'aea0155667924dff8a24e4cb35b9'
]
After compression (16 bytes): After compression (16 bytes):
Flag byte: 0b00001001 = 0x09 Flag byte: 0b00001001 = 0x09
Option Value: 09 00 (2 bytes) Option Value: 09 00 (2 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)
3. Request with kid = empty string, Partial IV = 0x05, and kid 3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
context = 0x44616c656b empty string, Partial IV = 0x05, and kid context = 0x44616c656b
Before compression (30 bytes):
[
h'',
{ 4:h'', 6:h'05', 8:h'44616c656b' },
h'aea0155667924dff8a24e4cb35b9'
]
After compression (22 bytes): After compression (22 bytes):
Flag byte: 0b00011001 = 0x19 Flag byte: 0b00011001 = 0x19
Option Value: 19 05 05 44 61 6c 65 6b (8 bytes) Option Value: 19 05 05 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)
6.3.2. Example: Response (without Observe) 6.3.2. Example: Response (without Observe)
1. Response not including an Observe option, with ciphertext =
0xaea0155667924dff8a24e4cb35b9
Before compression (18 bytes): Before compression (18 bytes):
[ [
h'', h'',
{}, {},
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
After compression (14 bytes): After compression (14 bytes):
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)
6.3.3. Example: Response (with Observe) 6.3.3. Example: Response (with Observe)
1. Response including an Observe option, with ciphertext =
0xaea0155667924dff8a24e4cb35b9 and Partial IV = 0x07
Before compression (21 bytes): Before compression (21 bytes):
[ [
h'', h'',
{ 6:h'07' }, { 6:h'07' },
h'aea0155667924dff8a24e4cb35b9' h'aea0155667924dff8a24e4cb35b9'
] ]
After compression (16 bytes): After compression (16 bytes):
skipping to change at page 30, line 8 skipping to change at page 30, line 52
7.2. AEAD Nonce Uniqueness 7.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), and no greater than 2^40 - 1. If the Sender Sequence Section 11), and SHALL be less than 2^40. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more Number exceeds the maximum, the endpoint MUST NOT process any more
messages with the given Sender Context. The endpoint SHOULD acquire messages with the given Sender Context. The endpoint SHOULD acquire
a new security context (and consequently inform the other endpoint) a new security context (and consequently inform the other endpoint)
before this happens. The latter is out of scope of this document. before this happens. The latter is out of scope of this document.
7.3. Freshness 7.3. Freshness
For requests, OSCORE provides only the guarantee that the request is For requests, OSCORE provides only the guarantee that the request is
not older than the security context. For applications having not older than the security context. For applications having
stronger demands on request freshness (e.g., control of actuators), stronger demands on request freshness (e.g., control of actuators),
skipping to change at page 30, line 40 skipping to change at page 31, line 35
recipient to determine the relative order of responses. recipient to determine the relative order of responses.
7.4. Replay Protection 7.4. Replay Protection
In order to protect from replay of requests, the server's Recipient In order to protect from replay of requests, the server's Recipient
Context includes a Replay Window. A server SHALL verify that a Context includes a Replay Window. A server SHALL verify that a
Partial IV received in the COSE object has not been received before. Partial IV received in the COSE object has not been received before.
If this verification fails the server SHALL stop processing the If this verification fails the server SHALL stop processing the
message, and MAY optionally respond with a 4.01 Unauthorized error message, and MAY optionally respond with a 4.01 Unauthorized error
message. Also, the server MAY set an Outer Max-Age option with value message. Also, the server MAY set an Outer Max-Age option with value
zero. The diagnostic payload MAY contain the "Replay protection zero. The diagnostic payload MAY contain the "Replay detected"
failed" string. The size and type of the Replay Window depends on string. The size and type of the Replay Window depends on the use
the use case and the protocol with which the OSCORE message is case and the protocol with which the OSCORE message is transported.
transported. In case of reliable and ordered transport from endpoint In case of reliable and ordered transport from endpoint to endpoint,
to endpoint, e.g. TCP, the server MAY just store the last received e.g. TCP, the server MAY just store the last received Partial IV and
Partial IV and require that newly received Partial IVs equals the require that newly received Partial IVs equals the last received
last received Partial IV + 1. However, in case of mixed reliable and Partial IV + 1. However, in case of mixed reliable and unreliable
unreliable transports and where messages may be lost, such a replay transports and where messages may be lost, such a replay mechanism
mechanism may be too restrictive and the default replay window be may be too restrictive and the default replay window be more suitable
more suitable (see Section 3.2.2). (see Section 3.2.2).
Responses to non-Observe requests are protected against replay as Responses to non-Observe requests are protected against replay as
they are cryptographically bound to the request. they are cryptographically bound to the request.
In the case of Observe, a client receiving a notification SHALL In the case of Observe, a client receiving a notification SHALL
verify that the Partial IV of a received notification is greater than verify that the Partial IV of a received notification is greater than
the Notification Number bound to that Observe registration. If the the Notification Number bound to that Observe registration. If the
verification fails, the client SHALL stop processing the response. verification fails, the client SHALL stop processing the response.
If the verification succeeds, the client SHALL overwrite the If the verification succeeds, the client SHALL overwrite the
corresponding Notification Number with the received Partial IV. corresponding Notification Number with the received Partial IV.
skipping to change at page 34, line 11 skipping to change at page 35, line 4
5. Compose the Additional Authenticated Data, as described in 5. Compose the Additional Authenticated Data, as described in
Section 5.4. Section 5.4.
6. Compute the AEAD nonce from the Recipient ID, Common IV, and the 6. Compute the AEAD nonce from the Recipient ID, Common IV, and the
'Partial IV' parameter, received in the COSE Object. 'Partial IV' parameter, received in the COSE Object.
7. Decrypt the COSE object using the Recipient Key, as per 7. Decrypt the COSE object using the Recipient Key, as per
[RFC8152] Section 5.3. (The decrypt operation includes the [RFC8152] Section 5.3. (The decrypt operation includes the
verification of the integrity.) verification of the integrity.)
* If decryption fails, the server MUST stop processing the * If decryption fails, the server MUST stop processing the
request and MAY respond with a 4.00 Bad Request error request and MAY respond with a 4.00 Bad Request error
message. The server MAY set an Outer Max-Age option with message. The server MAY set an Outer Max-Age option with
value zero. The diagnostic payload SHOULD contain the value zero. The diagnostic payload MAY contain the
"Decryption failed" string. "Decryption failed" string.
* If decryption succeeds, update the Replay Window, as * If decryption succeeds, update the Replay Window, as
described in Section 7. described in Section 7.
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:
the message contains a Max-Age Inner and a Max-Age Outer option. the message contains a Max-Age Inner and a Max-Age Outer option.
The Outer Max-Age is discarded. The Outer Max-Age is discarded.
9. Add decrypted code, options and payload to the decrypted 9. Add decrypted code, options and payload to the decrypted
request. The Object-Security option is removed. request. The Object-Security option is removed.
10. The decrypted CoAP request is processed according to [RFC7252] 10. The decrypted CoAP request is processed according to [RFC7252].
8.3. Protecting the Response 8.3. Protecting the Response
If a CoAP response is generated in response to an OSCORE request, the If a CoAP response is generated in response to an OSCORE request, the
server SHALL perform the following steps to create an OSCORE server SHALL perform the following steps to create an OSCORE
response. Note that CoAP error responses derived from CoAP response. Note that CoAP error responses derived from CoAP
processing (point 10. in Section 8.2) are protected, as well as processing (point 10. in Section 8.2) are protected, as well as
successful CoAP responses, while the OSCORE errors (point 3, 4, and 7 successful CoAP responses, while the OSCORE errors (point 3, 4, and 7
in Section 8.2) do not follow the processing below, but are sent as in Section 8.2) do not follow the processing below, but are sent as
simple CoAP responses, without OSCORE processing. simple CoAP responses, without OSCORE processing.
skipping to change at page 36, line 26 skipping to change at page 37, line 17
corresponding Notification Number, as described in Section 7. corresponding Notification Number, as described in Section 7.
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:
the message contains a Max-Age Inner and a Max-Age Outer option. the message contains a Max-Age Inner and a Max-Age Outer option.
The Outer Max-Age is discarded. The Outer Max-Age is discarded.
9. Add decrypted code, options and payload to the decrypted 9. Add decrypted code, options and payload to the decrypted
request. The Object-Security option is removed. request. The Object-Security option is removed.
10. The decrypted CoAP response is processed according to [RFC7252] 10. The decrypted CoAP response is processed according to [RFC7252].
11. (Optional) In case any of the previous erroneous conditions 11. In case any of the previous erroneous conditions apply: the
apply: the client SHALL stop processing the response. client SHALL stop processing the response.
An error condition occurring while processing a response in an An error condition occurring while processing a response in an
observation does not cancel the observation. A client MUST NOT react observation does not cancel the observation. A client MUST NOT react
to failure in step 7 by re-registering the observation immediately. to failure in step 7 by re-registering the observation immediately.
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 [RFC8288] 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
skipping to change at page 37, line 21 skipping to change at page 38, line 13
OSCORE-aware proxies. OSCORE-aware proxies.
10.1. CoAP-to-CoAP Forwarding Proxy 10.1. CoAP-to-CoAP Forwarding Proxy
OSCORE is designed to work with legacy CoAP-to-CoAP forward proxies OSCORE is designed to work with legacy CoAP-to-CoAP forward proxies
[RFC7252], but OSCORE-aware proxies MAY provide certain [RFC7252], but OSCORE-aware proxies MAY provide certain
simplifications as specified in this section. simplifications as specified in this section.
Security requirements for forwarding are presented in Section 2.2.1 Security requirements for forwarding are presented in Section 2.2.1
of [I-D.hartke-core-e2e-security-reqs]. OSCORE complies with the of [I-D.hartke-core-e2e-security-reqs]. OSCORE complies with the
extended security requirements also addressing Blockwise ([RFC7959]) extended security requirements also addressing Block-wise [RFC7959]
and CoAP-mappable HTTP. In particular caching is disabled since the and CoAP-mappable HTTP. In particular caching is disabled since the
CoAP response is only applicable to the original CoAP request. An CoAP response is only applicable to the original CoAP request. An
OSCORE-aware proxy SHALL NOT cache a response to a request with an OSCORE-aware proxy SHALL NOT cache a response to a request with an
Object-Security option. As a consequence, the search for cache hits Object-Security option. As a consequence, the search for cache hits
and CoAP freshness/Max-Age processing can be omitted. and CoAP freshness/Max-Age processing can be omitted.
Proxy processing of the (Outer) Proxy-Uri option is as defined in Proxy processing of the (Outer) Proxy-Uri option is as defined in
[RFC7252]. [RFC7252].
Proxy processing of the (Outer) Block options is as defined in Proxy processing of the (Outer) Block options is as defined in
[RFC7959]. [RFC7959].
Proxy processing of the (Outer) Observe option is as defined in Proxy processing of the (Outer) Observe option is as defined in
[RFC7641]. OSCORE-aware proxies MAY look at the Partial IV value [RFC7641]. OSCORE-aware proxies MAY look at the Partial IV value
instead of the Outer Observe option. instead of the Outer Observe option.
10.2. HTTP Processing 10.2. HTTP Processing
OSCORE was initially designed to work between CoAP endpoints only, In order to use OSCORE over HTTP hops, a node needs to be able to map
but the interest in use cases with one endpoint being an HTTP
endpoint has driven the extension specified here. OSCORE is intended
to be used with at least one endpoint being a CoAP endpoint.
In order to use OSCORE with HTTP, an endpoint needs to be able to map
HTTP messages to CoAP messages (see [RFC8075]), and to apply OSCORE HTTP messages to CoAP messages (see [RFC8075]), and to apply OSCORE
to CoAP messages (as defined in this document). to CoAP messages (as defined in this document).
For this purpose, this specification defines a new HTTP header field For this purpose, this specification defines a new HTTP header field
named CoAP-Object-Security, see Section 12.4. The CoAP-Object- named CoAP-Object-Security, see Section 12.4. The CoAP-Object-
Security header field is only used in POST requests and 200 (OK) Security header field is only used in POST requests and 200 (OK)
responses. All field semantics is given within the CoAP-Object- responses, i.e. essentially using HTTP as a transport of an encrypted
Security header field. The header field is neither appropriate to CoAP mappable message contained in the payload.
list in the Connection header field (see Section 6.1 of [RFC7230]),
nor in a Vary response header field (see Section 7.1.4 of [RFC7231]), The header field is neither appropriate to list in the Connection
nor allowed in trailers (see Section 4.1 of [RFC7230]). header field (see Section 6.1 of [RFC7230]), nor in a Vary response
Intermediaries are not allowed to insert, delete, or modify the header field (see Section 7.1.4 of [RFC7231]), nor allowed in
field's value. The header field is not preserved across redirects. trailers (see Section 4.1 of [RFC7230]).
[Ed. Note: Reconsider use of Vary]
Intermediaries cannot insert, delete, or modify the field's value
without being detected. The header field is not preserved across
redirects.
[Ed. Note: Reconsider support for redirects]
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234],
including the following core ABNF syntax rules defined by that
specification: ALPHA (letters) and DIGIT (decimal digits), the CoAP-
Object-Security header field is as follows.
base64-char = ALPHA / DIGIT / "_" / "-"
CoAP-Object-Security = 2*base64-char
A sending endpoint uses [RFC8075] to translate an HTTP message into a A sending endpoint uses [RFC8075] to translate an HTTP message into a
CoAP message. It then protects the message with OSCORE processing, CoAP message. It then protects the message with OSCORE processing,
and add the Object-Security option (as defined in this document). and adds the Object-Security option (as defined in this document).
Then, the endpoint maps the resulting CoAP message to an HTTP message Then, the endpoint maps the resulting CoAP message to an HTTP message
that includes the HTTP header field CoAP-Object-Security, whose value that includes the HTTP header field CoAP-Object-Security, whose value
is: is:
o "" if the CoAP Object-Security option is empty, or o "" if the CoAP Object-Security option is empty, or
o the value of the CoAP Object-Security option (Section 6.1) in o the value of the CoAP Object-Security option (Section 6.1) in
base64url encoding (Section 5 of [RFC4648]) without padding (see base64url encoding (Section 5 of [RFC4648]) without padding (see
[RFC7515] Appendix C for implementation notes for this encoding). [RFC7515] Appendix C for implementation notes for this encoding).
skipping to change at page 38, line 39 skipping to change at page 39, line 44
The resulting message is an OSCORE message that uses HTTP. The resulting message is an OSCORE message that uses HTTP.
A receiving endpoint uses [RFC8075] to translate an HTTP message into A receiving endpoint uses [RFC8075] to translate an HTTP message into
a CoAP message, with the following addition. The HTTP message a CoAP message, with the following addition. The HTTP message
includes the CoAP-Object-Security header field, which is mapped to includes the CoAP-Object-Security header field, which is mapped to
the CoAP Object-Security option in the following way. The CoAP the CoAP Object-Security option in the following way. The CoAP
Object-Security option value is: Object-Security option value is:
o empty if the value of the HTTP CoAP-Object-Security header field o empty if the value of the HTTP CoAP-Object-Security header field
is "" is a single zero byte (0x00) represented by AA
o the value of the HTTP CoAP-Object-Security header field decoded o the value of the HTTP CoAP-Object-Security header field decoded
from base64url (Section 5 of [RFC4648]) without padding (see from base64url (Section 5 of [RFC4648]) without padding (see
[RFC7515] Appendix C for implementation notes for this decoding). [RFC7515] Appendix C for implementation notes for this decoding).
Note that the value of the CoAP payload is the HTTP body, i.e. the Note that the value of the CoAP payload is the HTTP body, i.e. the
OSCORE payload (Section 6.2). OSCORE payload (Section 6.2).
The resulting message is an OSCORE message that uses CoAP. The resulting message is an OSCORE message that uses CoAP.
skipping to change at page 39, line 21 skipping to change at page 40, line 23
Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an
HTTP-to-CoAP proxy. As requested in Section 1 of [RFC8075], this HTTP-to-CoAP proxy. As requested in Section 1 of [RFC8075], this
section describes the HTTP mapping for the OSCORE protocol extension section describes the HTTP mapping for the OSCORE protocol extension
of CoAP. of CoAP.
The presence of the Object-Security option, both in requests and The presence of the Object-Security option, both in requests and
responses, is expressed in an HTTP header field named CoAP-Object- responses, is expressed in an HTTP header field named CoAP-Object-
Security in the mapped request or response. The value of the field Security in the mapped request or response. The value of the field
is: is:
o "" if the CoAP Object-Security option is empty, or o AA if the CoAP Object-Security option is empty, or
o the value of the CoAP Object-Security option (Section 6.1) in o the value of the CoAP Object-Security option (Section 6.1) in
base64url encoding (Section 5 of [RFC4648]) without padding (see base64url encoding (Section 5 of [RFC4648]) without padding (see
[RFC7515] Appendix C for implementation notes for this encoding). [RFC7515] Appendix C for implementation notes for this encoding).
The header field Content-Type 'application/oscore' (see Section 12.5) The header field Content-Type 'application/oscore' (see Section 12.5)
is used for OSCORE messages transported in HTTP. The CoAP Content- is used for OSCORE messages transported in HTTP. The CoAP Content-
Format option is omitted for OSCORE messages transported in CoAP. Format option is omitted for OSCORE messages transported in CoAP.
The value of the body is the OSCORE payload (Section 6.2). The value of the body is the OSCORE payload (Section 6.2).
skipping to change at page 42, line 28 skipping to change at page 43, line 28
11.1. End-to-end protection 11.1. End-to-end protection
In scenarios with intermediary nodes such as proxies or gateways, In scenarios with intermediary nodes such as proxies or gateways,
transport layer security such as (D)TLS only protects data hop-by- transport layer security such as (D)TLS only protects data hop-by-
hop. As a consequence, the intermediary nodes can read and modify hop. As a consequence, the intermediary nodes can read and modify
information. The trust model where all intermediary nodes are information. The trust model where all intermediary nodes are
considered trustworthy is problematic, not only from a privacy considered trustworthy is problematic, not only from a privacy
perspective, but also from a security perspective, as the perspective, but also from a security perspective, as the
intermediaries are free to delete resources on sensors and falsify intermediaries are free to delete resources on sensors and falsify
commands to actuators (such as "unlock door", "start fire alarm", commands to actuators (such as "unlock door", "start fire alarm",
"raise bridge"). Even in the rare cases, where all the owners of the "raise bridge"). Even in the rare cases where all the owners of the
intermediary nodes are fully trusted, attacks and data breaches make intermediary nodes are fully trusted, attacks and data breaches make
such an architecture brittle. such an architecture brittle.
(D)TLS protects hop-by-hop the entire message. OSCORE protects end- (D)TLS protects hop-by-hop the entire message. OSCORE protects end-
to-end all information that is not required for proxy operations (see to-end all information that is not required for proxy operations (see
Section 4). (D)TLS and OSCORE can be combined, thereby enabling end- Section 4). (D)TLS and OSCORE can be combined, thereby enabling end-
to-end security of the message payload, in combination with hop-by- to-end security of the message payload, in combination with hop-by-
hop protection of the entire message, during transport between end- hop protection of the entire message, during transport between end-
point and intermediary node. The CoAP messaging layer, including point and intermediary node. The CoAP messaging layer, including
header fields such as Type and Message ID, as well as CoAP message header fields such as Type and Message ID, as well as CoAP message
skipping to change at page 43, line 10 skipping to change at page 44, line 10
intermediary. Hop-by-hop protection of signaling messages can be intermediary. Hop-by-hop protection of signaling messages can be
achieved with (D)TLS. Applications using unprotected error and achieved with (D)TLS. Applications using unprotected error and
signaling messages need to consider the threat that these messages signaling messages need to consider the threat that these messages
may be spoofed. may be spoofed.
11.2. Security Context Establishment 11.2. Security Context Establishment
The use of COSE to protect messages as specified in this document The use of COSE to protect messages as specified in this document
requires an established security context. The method to establish requires an established security context. The method to establish
the security context described in Section 3.2 is based on a common the security context described in Section 3.2 is based on a common
shared secret material in client and server, which may be obtained, keying material in client and server, which may be obtained, e.g., by
e.g., by using the ACE framework [I-D.ietf-ace-oauth-authz]. An using the ACE framework [I-D.ietf-ace-oauth-authz]. An OSCORE
OSCORE profile of ACE is described in [I-D.ietf-ace-oscore-profile]. profile of ACE is described in [I-D.ietf-ace-oscore-profile]. The
key establishement procedure need to ensure same key is not installed
twice, even in error situations.
11.3. Replay Protection 11.3. Replay Protection
Most AEAD algorithms require a unique nonce for each message, for Most AEAD algorithms require a unique nonce for each message, for
which the sender sequence numbers in the COSE message field 'Partial which the sender sequence numbers in the COSE message field 'Partial
IV' is used. If the recipient accepts any sequence number larger IV' is used. If the recipient accepts any sequence number larger
than the one previously received, then the problem of sequence number than the one previously received, then the problem of sequence number
synchronization is avoided. With reliable transport, it may be synchronization is avoided. With reliable transport, it may be
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.
11.4. Cryptographic Considerations 11.4. Cryptographic Considerations
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 is 2^40 - 1, or any
any algorithm specific lower limit, after which a new security algorithm specific lower limit, after which a new security context
context must be generated. The mechanism to build the nonce must be generated. The mechanism to build the nonce (Section 5.2)
(Section 5.2) assumes that the nonce is at least 56 bit-long, and the assumes that the nonce is at least 56 bits, and the Partial IV is at
Partial IV is at most 40 bit-long. The mandatory-to-implement AEAD most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM-
algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*. 16-64-128 is selected for compatibility with CCM*.
The security level of a system with m Masters Keys of length k used The security level of a system with m Masters Keys of length k used
together with Master Salts with entropy n is k + n - log2(m). together with Master Salts with entropy n is k + n - log2(m).
Similarly, the security level of a system with m AEAD keys of length Similarly, the security level of a system with m AEAD keys of length
k used together with AEAD nonces of length n is k + n - log2(m). k used together with AEAD nonces of length n is k + n - log2(m).
Security level here means that an attacker can recover one of the m Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of can be provided by increasing the size of the keys or the entropy of
the Master Salt. The complexity of recovering a specific key is the Master Salt. The complexity of recovering a specific key is
still 2^k (assuming the Master Salt/AEAD nonce is public). The still 2^k (assuming the Master Salt/AEAD nonce is public) (see [MF00]
Master Secret, Sender Key, and Recipient Key MUST be secret, the rest for a overview). The Master Secret, Sender Key, and Recipient Key
of the parameters MAY be public. The Master Secret MUST be uniformly must be secret, the rest of the parameters may be public. The Master
random. Secret must be uniformly random.
11.5. Message Fragmentation 11.5. Message Segmentation
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 endpoint can into OSCORE-protected blocks such that the receiving endpoint can
verify blocks before having received the complete message. The Outer verify blocks before having received the complete message. The Outer
Block options allow for arbitrary proxy fragmentation operations that Block 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 Inner Block options allow for secure fragmentation in size since the Inner Block options allow for secure fragmentation
of very large messages. A maximum message size (above which the of very large messages. A maximum message size (above which the
sending endpoint fragments the message and the receiving endpoint sending endpoint fragments the message and the receiving endpoint
discards the message, if complying to the policy) may be obtained as discards the message, if complying to the policy) may be obtained as
skipping to change at page 44, line 45 skipping to change at page 45, line 45
Unprotected error messages reveal information about the security Unprotected error messages reveal information about the security
state in the communication between the endpoints. Unprotected state in the communication between the endpoints. Unprotected
signalling messages reveal information about the reliable transport signalling messages reveal information about the reliable transport
used on a leg of the path. Using the mechanisms described in used on a leg of the path. Using the mechanisms described in
Section 7.5 may reveal when a device goes through a reboot. This can Section 7.5 may reveal when a device goes through a reboot. This can
be mitigated by the device storing the precise state of sender be mitigated by the device storing the precise state of sender
sequence number and replay window on a clean shutdown. sequence number and replay window on a clean shutdown.
The length of message fields can reveal information about the The length of message fields can reveal information about the
message. Applications may use a padding scheme to protect against message. Applications may use a padding scheme to protect against
traffic analysis. As an example, the strings "YES" and "NO" even if traffic analysis.
encrypted can be distinguished from each other as there is no padding
supplied by the current set of encryption algorithms. Some
information can be determined even from looking at boundary
conditions. An example of this would be returning an integer between
0 and 100 where lengths of 1, 2 and 3 will provide information about
where in the range things are. Three different methods to deal with
this are: 1) ensure that all messages are the same length. For
example, using 0 and 1 instead of "yes" and "no". 2) Use a character
which is not part of the responses to pad to a fixed length. For
example, pad with a space to three characters. 3) Use the PKCS #7
style padding scheme where m bytes are appended each having the value
of m. For example, appending a 0 to "YES" and two 1's to "NO". This
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
12. IANA Considerations 12. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification. document]]" with the RFC number of this specification.
Note to IANA: Please note all occurrences of "TBD" in this Note to IANA: Please note all occurrences of "TBD" in this
specification should be assigned the same number. specification should be assigned the same number.
12.1. COSE Header Parameters Registry 12.1. COSE Header Parameters Registry
skipping to change at page 46, line 13 skipping to change at page 46, line 44
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
12.3. CoAP Signaling Option Numbers Registry 12.3. CoAP Signaling Option Numbers Registry
The Object-Security option is added to the CoAP Signaling Option The Object-Security option is added to the CoAP Signaling Option
Numbers registry: Numbers registry:
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| 7.xx | TBD | Object-Security | [[this document]] | | 7.xx (any) | TBD | Object-Security | [[this document]] |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
12.4. Header Field Registrations 12.4. Header Field Registrations
The HTTP header field CoAP-Object-Security is added to the Message The HTTP header field CoAP-Object-Security is added to the Message
Headers registry: Headers registry:
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
skipping to change at page 48, line 5 skipping to change at page 49, line 5
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: Goeran Selander, goran.selander@ericsson.com Author: Goeran Selander, goran.selander@ericsson.com
Change Controller: IESG Change Controller: IESG
Provisional registration? No Provisional registration? No
12.6. CoAP Content-Formats Registry
TODO
13. References 13. References
13.1. Normative References 13.1. Normative References
[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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc- DOI 10.17487/RFC7231, June 2014,
editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
the Constrained Application Protocol (CoAP)", RFC 7390,
DOI 10.17487/RFC7390, October 2014,
<https://www.rfc-editor.org/info/rfc7390>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, <https://www.rfc- DOI 10.17487/RFC7641, September 2015,
editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, <https://www.rfc- DOI 10.17487/RFC7959, August 2016,
editor.org/info/rfc7959>. <https://www.rfc-editor.org/info/rfc7959>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075, the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017, <https://www.rfc- DOI 10.17487/RFC8075, February 2017,
editor.org/info/rfc8075>. <https://www.rfc-editor.org/info/rfc8075>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, <https://www.rfc- DOI 10.17487/RFC8288, October 2017,
editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
13.2. Informative References 13.2. Informative References
[I-D.bormann-6lo-coap-802-15-ie] [I-D.bormann-6lo-coap-802-15-ie]
skipping to change at page 50, line 12 skipping to change at page 51, line 30
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-05 (work in progress), March 2018. 6tisch-minimal-security-05 (work in progress), March 2018.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-oauth- Constrained Environments (ACE)", draft-ietf-ace-oauth-
authz-10 (work in progress), February 2018. authz-10 (work in progress), February 2018.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander,
profile of the Authentication and Authorization for "OSCORE profile of the Authentication and Authorization
Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-00 (work in progress), December 2017. oscore-profile-01 (work in progress), March 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-02 express CBOR data structures", draft-ietf-cbor-cddl-02
(work in progress), February 2018. (work in progress), February 2018.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "Echo and Amsuess, C., Mattsson, J., and G. Selander, "Echo and
Request-Tag", draft-ietf-core-echo-request-tag-00 (work in Request-Tag", draft-ietf-core-echo-request-tag-01 (work in
progress), October 2017. progress), March 2018.
[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., and J. Park,
"Secure group communication for CoAP", draft-ietf-core- "Secure group communication for CoAP", draft-ietf-core-
oscore-groupcomm-01 (work in progress), March 2018. oscore-groupcomm-01 (work in progress), March 2018.
[I-D.mattsson-ace-tls-oscore]
Mattsson, J., "Using Transport Layer Security (TLS) to
Secure OSCORE", draft-mattsson-ace-tls-oscore-00 (work in
progress), October 2017.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-04 (work in progress), March mattsson-core-coap-actuators-04 (work in progress), March
2018. 2018.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-07 (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>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>. <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010, <https://www.rfc- DOI 10.17487/RFC5869, May 2010,
editor.org/info/rfc5869>. <https://www.rfc-editor.org/info/rfc5869>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, <https://www.rfc- DOI 10.17487/RFC7228, May 2014,
editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
skipping to change at page 63, line 5 skipping to change at page 64, line 5
o Object-Security value: 0x0100 (2 bytes) o Object-Security value: 0x0100 (2 bytes)
o ciphertext: 0xa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (22 o ciphertext: 0xa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (22
bytes) bytes)
From there: From there:
o Protected CoAP response (OSCORE message): 0x64442b130000b29ed20801 o Protected CoAP response (OSCORE message): 0x64442b130000b29ed20801
00ffa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (35 bytes) 00ffa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (35 bytes)
Appendix D. Security properties Appendix D. Overview of Security Properties
This appendix discusses security properties of OSCORE. D.1. Supporting Proxy Operations
TODO CoAP is designed to work with intermediaries reading and/or changing
CoAP message fields and performing supporting operations in
constrained environments, e.g. forwarding and cross-protocol
translations.
Securing CoAP on transport layer protects the entire message between
the endpoints in which case CoAP proxy operations are not possible.
In order to enable proxy operations, security on transport layer
needs to be terminated at the proxy in which case the CoAP message in
its entirety is unprotected in the proxy.
Requirements for CoAP end-to-end security are specified in
[I-D.hartke-core-e2e-security-reqs]. The client and server are
assumed to trust each other, but proxies and gateways are only
trusted to perform its intended operations. Forwarding is specified
in Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs]. HTTP-CoAP
translation is specified in [RFC8075]. Intermediaries translating
between different transport layers are intended to perform just that.
By working at the CoAP layer, OSCORE enables different CoAP message
fields to be protected differently, which allows message fields
required for proxy operations to be available to the proxy while
message fields intended for the other endpoint remain protected. In
the remainder of this section we analyze how OSCORE protects the
protected message fields and the consequences of message fields
intended for proxy operation being unprotected.
D.2. Protected Message Fields
Protected message fields are included in the Plaintext (Section 5.3)
and the Additional Authenticated Data (Section 5.4) of the
COSE_Encrypt0 object using an AEAD algorithm.
OSCORE depends on a pre-established strong Master Secret which can be
used to derive keys, and a construction for making (key, nonce) pairs
unique (Appendix D.3). Assuming this is true, and the keys are used
for no more data than indicated in Section 7.2, OSCORE should provide
the following guarantees:
o Confidentiality: An attacker should not be able to determine the
plaintext contents of a given OSCORE message or determine that
different plaintexts are related (Section 5.3).
o Integrity: An attacker should not be able to craft a new OSCORE
message with protected message fields different from an existing
OSCORE message which will be accepted by the receiver.
o Request-response binding: An attacker should not be able to make a
client match a response to the wrong request.
o Non-replayability: An attacker should not be able to cause the
receiver to accept a message which it has already accepted.
Informally, OSCORE provides these properties by AEAD-protecting the
plaintext with a strong key and uniqueness of (key, nonce) pairs.
AEAD encryption [RFC5116] provides confidentiality and integrity for
the data. Response-request binding is provided by including the kid
and Partial IV of the request in the AAD of the response. Non-
replayability of requests and notifications is provided by using
unique (key, nonce) pairs and a replay protection mechanism
(application dependent, see Section 7.4).
OSCORE is susceptible to a variety of traffic analysis attacks based
on observing the length and timing of encrypted packets. OSCORE does
not provide any specific defenses against this form of attack but the
application may use a padding mechanism to prevent an attacker from
directly determine the length of the padding. However, information
about padding may still be revealed by side-channel attacks observing
differences in timing.
D.3. Uniqueness of (key, nonce)
In this section we show (key, nonce) pairs are not reused in the
encryption of OSCORE messages.
Fix a Security Context complying with the requirements Section 3.3)
and an endpoint. Endpoints may alternate between Client and Server
roles, but each endpoint encrypts with the Sender Key of its Sender
Context. Sender Keys are (stochastically) unique since they are
derived with HKDF from unique Sender IDs, so messages encrypted by
different endpoints use different keys. It remains to prove that the
nonces used by the fixed endpoint are unique.
Since the Common IV is fixed, the nonces are determined by a Partial
IV (PIV) and the Sender ID of the endpoint generating that Partial IV
(ID_PIV), and are unique for different (ID_PIV, PIV) pairs
(Section 5.2).
For requests and notifications (GET Observe responses):
o ID_PIV = Sender ID of the encrypting endpoint
o PIV = current Partial IV of the encrypting endpoint
Since the encrypting endpoint steps the Partial IV for each use, the
nonces used in requests and notifications are all unique as long as
the number of encrypted messages are kept within the required range
(Section 7.2).
For responses to requests:
o ID_PIV = Sender ID of the endpoint generating the request
o PIV = Partial IV of the request
Since the request has been verified using the Recipient Context,
ID_PIV is the Sender ID of another endpoint and is thus different
from the Sender ID of the encrypting endpoint. Therefore the nonces
used in responses are different compared to nonces in requests and
notifications. Since the Partial IV of the request is verified for
replay (Section 7.4), PIV is unique for responses and so are nonces
used in responses.
Note that the argument does not depend on if the nonce in the first
response to GET Observe is generated as a notification or as a
response to a request. In the former case the Partial IV of the
encrypting endpoint is stepped. In the latter case, the nonce is in
the the requesting endpoint's subset of nonces and would otherwise
not be used by the encrypting endpoint.
The argumentation also holds for group communication as specified in
[RFC7390] although Observe is not used for that setting (see
[I-D.ietf-core-oscore-groupcomm]).
D.4. Unprotected Message Fields
This section lists and discusses issues with unprotected CoAP message
fields.
D.4.1. CoAP Header Fields
o Version
The CoAP version will be in plaintext. A change of this parameter is
potentially a denial of service attack. Currently there is only one
CoAP version defined. Future versions of CoAP need to analyse
attacks to OSCORE protected messages due to an adversary changing the
CoAP version.
o Token/Token Length
The Token field is a client-local identifier for differentiating
between concurrent requests. Change of Token is a denial of service
attack, since the client may not be able to identify the request or
verify integrity of the response, which depends on the request.
o Type/Message ID
These fields reveal information about the UDP transport binding.
CoAP proxies are allowed to change Type and Message ID. These
message fields are not present in CoAP over TCP, and does not impact
the request/response message. A change of these fields is a denial
of service attack similar to changing UDP header fields.
o Length
This field reveal information about the TCP transport binding. These
message fields are not present in CoAP over UDP, and does not impact
the request/response message. A change of Length is a denial of
service attack similar to changing TCP header fields.
D.4.2. CoAP Options
o Max-Age
The Outer Max-Age is used to avoid unnecessary caching of OSCORE
error responses. Changing this value is a potential denial of
service attack.
o Proxy-Uri/Proxy-Scheme/Uri-Host/Uri-Port
With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-
Query parts of the URI. Proxy-Uri/Proxy-Scheme/Uri-Host/Uri-Port
cannot be integrity protected since they are allowed to be changed by
a forward proxy.
o Observe
The Outer Observe option is intended for an OSCORE-unaware proxy to
support forwarding of Observe messages. Changing this option may
lead to notifications not being forwarded.
o Block1/Block2/Size1/Size2
The Outer Block options enables fragmentation of OSCORE messages in
addition to segmentation performed by the Inner Block options.
Manipulating these options is a potential denial of service attack,
e.g. injection of alleged Block fragments up to the
MAX_UNFRAGMENTED_SIZE, at which the message will be dropped.
o No-Response
The Outer No-Response option is used to support proxy functionality,
specifically to avoid error transmissions from proxies to clients,
and to avoid bandwidth reduction to servers by proxies applying
congestion control when not receiving responses. Changing this
option is a potential denial of service attack.
o Object-Security
The Object-Security option contains information about the compressed
COSE header. A change of this field may result in not being able to
verify the OSCORE message.
Appendix E. CDDL Summary Appendix E. CDDL Summary
Data structure definitions in the present specification employ the Data structure definitions in the present specification employ the
CDDL language for conciseness and precision. CDDL is defined in CDDL language for conciseness and precision. CDDL is defined in
[I-D.ietf-cbor-cddl], which at the time of writing this appendix is [I-D.ietf-cbor-cddl], which at the time of writing this appendix is
in the process of completion. As the document is not yet available in the process of completion. As the document is not yet available
for a normative reference, the present appendix defines the small for a normative reference, the present appendix defines the small
subset of CDDL that is being used in the present specification. subset of CDDL that is being used in the present specification.
 End of changes. 80 change blocks. 
210 lines changed or deleted 452 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/