draft-ietf-core-object-security-16.txt   rfc8613.txt 
CoRE Working Group G. Selander Internet Engineering Task Force (IETF) G. Selander
Internet-Draft J. Mattsson Request for Comments: 8613 J. Mattsson
Updates: 7252 (if approved) F. Palombini Updates: 7252 F. Palombini
Intended status: Standards Track Ericsson AB Category: Standards Track Ericsson AB
Expires: September 7, 2019 L. Seitz ISSN: 2070-1721 L. Seitz
RISE SICS RISE
March 06, 2019 July 2019
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-16
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.
Although being an optional functionality of CoAP, OSCORE alters CoAP Although an optional functionality of CoAP, OSCORE alters CoAP
options processing and IANA registration. Therefore, this document options processing and IANA registration. Therefore, this document
updates [RFC7252]. updates RFC 7252.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on September 7, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8613.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 7 2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 8
3. The Security Context . . . . . . . . . . . . . . . . . . . . 7 3. The Security Context . . . . . . . . . . . . . . . . . . . . 8
3.1. Security Context Definition . . . . . . . . . . . . . . . 8 3.1. Security Context Definition . . . . . . . . . . . . . . . 9
3.2. Establishment of Security Context Parameters . . . . . . 10 3.2. Establishment of Security Context Parameters . . . . . . 11
3.3. Requirements on the Security Context Parameters . . . . . 12 3.3. Requirements on the Security Context Parameters . . . . . 14
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 13 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 15
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14 4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 16
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 23 4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 24
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 23 4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 25
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 24 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 26
5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 25 5.1. ID Context and 'kid context' . . . . . . . . . . . . . . 27
5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 26 5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 28
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 28 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 30
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 29 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 31
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 30 6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 32
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 31 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 33
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 31 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 33
7. Message Binding, Sequence Numbers, Freshness, and Replay 7. Message Binding, Sequence Numbers, Freshness, and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 34 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 34 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 36
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 34 7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 36
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 34 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 36
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 35 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 37
7.5. Losing Part of the Context State . . . . . . . . . . . . 36 7.5. Losing Part of the Context State . . . . . . . . . . . . 38
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 37 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 37 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 39
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 37 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 40
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 39 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 41
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 40 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 43
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 44
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 42 10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 45
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 43 11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 46
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 43 11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 46
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 44 11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 47
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 45 11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 48
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 45 11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 48
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 46 11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 48
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 47 11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 50
12. Security Considerations . . . . . . . . . . . . . . . . . . . 48 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 48 12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 51
12.2. Security Context Establishment . . . . . . . . . . . . . 49 12.2. Security Context Establishment . . . . . . . . . . . . . 52
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 49 12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 52
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 50 12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 53
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 50 12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 53
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 50 12.6. Cryptographic Considerations . . . . . . . . . . . . . . 53
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 51 12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 54
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 51 12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 54
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 52 13.1. COSE Header Parameters Registry . . . . . . . . . . . . 55
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 53 13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 55
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 54 13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 56
13.4. Header Field Registrations . . . . . . . . . . . . . . . 54 13.4. Header Field Registrations . . . . . . . . . . . . . . . 57
13.5. Media Type Registrations . . . . . . . . . . . . . . . . 54 13.5. Media Type Registration . . . . . . . . . . . . . . . . 57
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 56 13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 58
13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 56 13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 58
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 57 13.8. Expert Review Instructions . . . . . . . . . . . . . . . 59
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
14.1. Normative References . . . . . . . . . . . . . . . . . . 58 14.1. Normative References . . . . . . . . . . . . . . . . . . 60
14.2. Informative References . . . . . . . . . . . . . . . . . 59 14.2. Informative References . . . . . . . . . . . . . . . . . 62
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 62 Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 65
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 62 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 65
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 63 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 66
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 64 Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 68
B.1. Security Context Derived Once . . . . . . . . . . . . . . 64 B.1. Security Context Derived Once . . . . . . . . . . . . . . 68
B.2. Security Context Derived Multiple Times . . . . . . . . . 66 B.2. Security Context Derived Multiple Times . . . . . . . . . 70
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 71 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 75
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 72 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 75
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 73 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 77
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 75 C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 78
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 76 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 80
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 77 C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 81
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 79 C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 82
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 80 C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 84
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 81 C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 85
Appendix D. Overview of Security Properties . . . . . . . . . . 82 Appendix D. Overview of Security Properties . . . . . . . . . . 86
D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 82 D.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 86
D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 83 D.2. Supporting Proxy Operations . . . . . . . . . . . . . . . 87
D.3. Protected Message Fields . . . . . . . . . . . . . . . . 84 D.3. Protected Message Fields . . . . . . . . . . . . . . . . 87
D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 85 D.4. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 88
D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 86 D.5. Unprotected Message Fields . . . . . . . . . . . . . . . 89
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 89 Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 93
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 90 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a web The Constrained Application Protocol (CoAP) [RFC7252] is a web
transfer 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]; CoAP may be mapped from HTTP [RFC8075]. CoAP specifies
use of proxies for scalability and efficiency and references DTLS the use of proxies for scalability and efficiency and references DTLS
[RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
proxies require DTLS or TLS [RFC8446] to be terminated at the proxy. proxies require DTLS or TLS [RFC8446] to be terminated at the proxy.
The proxy therefore not only has access to the data required for Therefore, the proxy not only has access to the data required for
performing the intended proxy functionality, but is also able to performing the intended proxy functionality, but is also able to
eavesdrop on, or manipulate any part of, the message payload and eavesdrop on, or manipulate any part of, the message payload and
metadata in transit between the endpoints. The proxy can also metadata in transit between the endpoints. The proxy can also
inject, delete, or reorder packets since they are no longer protected inject, delete, or reorder packets since they are no longer protected
by (D)TLS. 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 the Observe CoAP features defined in [RFC7252], OSCORE supports the Observe
[RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options, [RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options,
as well as the PATCH and FETCH methods [RFC8132]. An analysis of as well as the PATCH and FETCH methods [RFC8132]. An analysis of
end-to-end security for CoAP messages through some types of end-to-end security for CoAP messages through some types of
intermediary nodes is performed in intermediary nodes is performed in [CoAP-E2E-Sec]. OSCORE
[I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the essentially protects the RESTful interactions: the request method,
RESTful interactions; the request method, the requested resource, the the requested resource, the message payload, etc. (see Section 4),
message payload, etc. (see Section 4). OSCORE protects neither the where "RESTful" refers to the Representational State Transfer (REST)
CoAP Messaging Layer nor the CoAP Token which may change between the Architecture [REST]. OSCORE protects neither the CoAP messaging
endpoints, and those are therefore processed as defined in [RFC7252]. layer nor the CoAP Token, which may change between the endpoints;
therefore, those are 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
to both unreliable and reliable transports (see Figure 1). to both unreliable and reliable transports (see Figure 1).
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 may be used over any underlying are given in Appendix A. OSCORE may be used over any underlying
layer, such as e.g. UDP or TCP, and with non-IP transports (e.g., layer, such as UDP or TCP, and with non-IP transports (e.g.,
[CoAP-802.15.4]). OSCORE may also be used in different ways with
[I-D.bormann-6lo-coap-802-15-ie]). OSCORE may also be used in HTTP. OSCORE messages may be transported in HTTP, and OSCORE may
different ways with HTTP. OSCORE messages may be transported in also be used to protect CoAP-mappable HTTP messages, as described
HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP below.
messages, as described below.
+-----------------------------------+ +-----------------------------------+
| Application | | Application |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses / Signaling | | | Requests / Responses / Signaling | |
|-----------------------------------| | |-----------------------------------| |
| OSCORE | | CoAP | OSCORE | | CoAP
|-----------------------------------| | |-----------------------------------| |
| Messaging Layer / Message Framing | | | Messaging Layer / Message Framing | |
skipping to change at page 5, line 32 skipping to change at page 6, line 27
+-----------------------------------+ +-----------------------------------+
Figure 1: Abstract Layering of CoAP with OSCORE Figure 1: Abstract Layering of CoAP with OSCORE
OSCORE is designed to protect as much information as possible while OSCORE is designed to protect as much information as possible while
still allowing CoAP proxy operations (Section 10). It works with still allowing CoAP proxy operations (Section 10). It works with
existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware existing CoAP-to-CoAP forward proxies [RFC7252], but an OSCORE-aware
proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and
CoAP-to-HTTP proxies can also be used with OSCORE, as specified in CoAP-to-HTTP proxies can also be used with OSCORE, as specified in
Section 11. OSCORE may be used together with TLS or DTLS over one or Section 11. OSCORE may be used together with TLS or DTLS over one or
more hops in the end-to-end path, e.g. transported with HTTPS in one more hops in the end-to-end path, e.g., transported with HTTPS in one
hop and with plain CoAP in another hop. The use of OSCORE does not hop and with plain CoAP in another hop. The use of OSCORE does not
affect the URI scheme and OSCORE can therefore be used with any URI affect the URI scheme; therefore, OSCORE can be used with any URI
scheme defined for CoAP or HTTP. The application decides the scheme defined for CoAP or HTTP. The application decides the
conditions for which OSCORE is required. conditions for which OSCORE is required.
OSCORE uses pre-shared keys which may have been established out-of- OSCORE uses pre-shared keys that 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
protection, and binding of response to request. A compressed version protection, and binding of response to request. A compressed version
of COSE is used, as specified in Section 6. The use of OSCORE is of COSE is used, as specified in Section 6. The use of OSCORE is
signaled in CoAP with a new option (Section 2), and in HTTP with a signaled in CoAP with a new option (Section 2), and in HTTP with a
new header field (Section 11.1) and content type (Section 13.5). The new header field (Section 11.1) and content type (Section 13.5). The
solution transforms a CoAP/HTTP message into an "OSCORE message" solution transforms a CoAP/HTTP message into an "OSCORE message"
before sending, and vice versa after receiving. The OSCORE message before sending, and vice versa after receiving. The OSCORE message
is a CoAP/HTTP message related to the original message in the is a CoAP/HTTP message related to the original message in the
skipping to change at page 6, line 33 skipping to change at page 7, line 29
Figure 2: Sketch of CoAP with OSCORE Figure 2: Sketch of CoAP with OSCORE
An implementation supporting this specification MAY implement only An implementation supporting this specification MAY implement only
the client part, MAY implement only the server part, or MAY implement the client part, MAY implement only the server part, or MAY implement
only one of the proxy parts. only one of the proxy parts.
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 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], Block-wise [RFC7959], described in CoAP [RFC7252], COSE [RFC8152], Concise Binary Object
COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl] as Representation (CBOR) [RFC7049], Concise Data Definition Language
summarized in Appendix E, and constrained environments [RFC7228]. (CDDL) [RFC8610] as summarized in Appendix E, and constrained
environments [RFC7228]. Additional optional features include Observe
[RFC7641], Block-wise [RFC7959], No-Response [RFC7967] and CoAP over
reliable transport [RFC8323].
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
that the message is not passed up to the CoAP Request/Response Layer that the message is not passed up to the CoAP request/response layer
(see Figure 1). (see Figure 1).
The terms Common/Sender/Recipient Context, Master Secret/Salt, Sender The terms Common Context, Sender Context, Recipient Context, Master
ID/Key, Recipient ID/Key, ID Context, and Common IV are defined in Secret, Master Salt, Sender ID, Sender Key, Recipient ID, Recipient
Section 3.1. Key, ID Context, and Common IV are defined in Section 3.1.
2. The OSCORE Option 2. The OSCORE Option
The OSCORE option defined in this section (see Figure 3, which The OSCORE option defined in this section (see Figure 3, which
extends Table 4: Options of [RFC7252]) indicates that the CoAP extends "Table 4: Options" of [RFC7252]) indicates that the CoAP
message is an OSCORE message and that it contains a compressed COSE message is an OSCORE message and that it contains a compressed COSE
object (see Sections 5 and 6). The OSCORE option is critical, safe object (see Sections 5 and 6). The OSCORE option is critical, safe
to forward, part of the cache key, and not repeatable. to forward, part of the cache key, and not repeatable.
+------+---+---+---+---+----------------+--------+--------+---------+ +------+---+---+---+---+----------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default | | No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+----------------+--------+--------+---------+ +------+---+---+---+---+----------------+--------+--------+---------+
| TBD1 | x | | | | OSCORE | (*) | 0-255 | (none) | | 9 | x | | | | OSCORE | (*) | 0-255 | (none) |
+------+---+---+---+---+----------------+--------+--------+---------+ +------+---+---+---+---+----------------+--------+--------+---------+
C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable
(*) See below. (*) See below.
Figure 3: The OSCORE Option Figure 3: The OSCORE Option
The OSCORE option includes the OSCORE flag bits (Section 6), the The OSCORE option includes the OSCORE flag bits (Section 6), the
Sender Sequence Number, the Sender ID, and the ID Context when these Sender Sequence Number, the Sender ID, and the ID Context when these
fields are present (Section 3). The detailed format and length is fields are present (Section 3). The detailed format and length is
specified in Section 6. If the OSCORE flag bits are all zero (0x00) specified in Section 6. If the OSCORE flag bits are all zero (0x00),
the Option value SHALL be empty (Option Length = 0). An endpoint the option value SHALL be empty (Option Length = 0). An endpoint
receiving a CoAP message without payload, that also contains an receiving a CoAP message without payload that also contains an OSCORE
OSCORE option SHALL treat it as malformed and reject it. option SHALL treat it as malformed and reject it.
A successful response to a request with the OSCORE option SHALL A successful response to a request with the OSCORE option SHALL
contain the OSCORE option. Whether error responses contain the contain the OSCORE option. Whether error responses contain the
OSCORE option depends on the error type (see Section 8). OSCORE option depends on the error type (see Section 8).
For CoAP proxy operations, see Section 10. For CoAP proxy operations, see Section 10.
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 Associated 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. function.
3.1. Security Context Definition 3.1. Security Context Definition
The security context is the set of information elements necessary to The security context is the set of information elements necessary to
carry out the cryptographic operations in OSCORE. For each endpoint, carry out the cryptographic operations in OSCORE. For each endpoint,
the security context is composed of a "Common Context", a "Sender the security context is composed of a "Common Context", a "Sender
Context", and a "Recipient Context". Context", and a "Recipient Context".
The endpoints protect messages to send using the Sender Context and The endpoints protect messages to send using the Sender Context and
verify messages received using the Recipient Context, both contexts verify messages received using the Recipient Context; both contexts
being derived from the Common Context and other data. Clients and being derived from the Common Context and other data. Clients and
servers need to be able to retrieve the correct security context to servers need to be able to retrieve the correct security context to
use. use.
An endpoint uses its Sender ID (SID) to derive its Sender Context, An endpoint uses its Sender ID (SID) to derive its Sender Context;
and the other endpoint uses the same ID, now called Recipient ID the other endpoint uses the same ID, now called Recipient ID (RID),
(RID), to derive its Recipient Context. In communication between two to derive its Recipient Context. In communication between two
endpoints, the Sender Context of one endpoint matches the Recipient endpoints, the Sender Context of one endpoint matches the Recipient
Context of the other endpoint, and vice versa. Thus, the two Context of the other endpoint, and vice versa. Thus, the two
security contexts identified by the same IDs in the two endpoints are security contexts identified by the same IDs in the two endpoints are
not the same, but they are partly mirrored. Retrieval and use of the not the same, but they are partly mirrored. Retrieval and use of the
security context are shown in Figure 4. security context are shown in Figure 4.
.-----------------------------------------------. .---------------------. .---------------------.
| Common Context | | Common Context | = | Common Context |
+---------------------.---.---------------------+ +---------------------+ +---------------------+
| Sender Context | = | Recipient Context | | Sender Context | = | Recipient Context |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| Recipient Context | = | Sender Context | | Recipient Context | = | Sender Context |
'---------------------' '---------------------' '---------------------' '---------------------'
Client Server Client Server
| | | |
Retrieve context for | OSCORE request: | Retrieve context for | OSCORE request: |
target resource | Token = Token1, | target resource | Token = Token1, |
Protect request with | kid = SID, ... | Protect request with | kid = SID, ... |
Sender Context +---------------------->| Retrieve context with Sender Context +---------------------->| Retrieve context with
skipping to change at page 9, line 7 skipping to change at page 10, line 9
Token = Token1 | | Token = Token1 | |
Verify request with | | Verify request with | |
Recipient Context | | Recipient Context | |
Figure 4: Retrieval and Use of the Security Context Figure 4: Retrieval and Use of the Security Context
The Common Context contains the following parameters: The Common Context contains the following parameters:
o AEAD Algorithm. The COSE AEAD algorithm to use for encryption. o AEAD Algorithm. The COSE AEAD algorithm to use for encryption.
o HKDF Algorithm. An HMAC-based key derivation function HKDF o HKDF Algorithm. An HMAC-based key derivation function (HKDF,
[RFC5869] used to derive Sender Key, Recipient Key, and Common IV. [RFC5869]) used to derive the Sender Key, Recipient Key, and
Common IV.
o Master Secret. Variable length, random byte string (see o Master Secret. Variable length, random byte string (see
Section 12.3) used to derive AEAD keys and Common IV. Section 12.3) used to derive AEAD keys and Common IV.
o Master Salt. Optional variable length byte string containing the o Master Salt. Optional variable-length byte string containing the
salt used to derive AEAD keys and Common IV. salt used to derive AEAD keys and Common IV.
o ID Context. Optional variable length byte string providing o ID Context. Optional variable-length byte string providing
additional information to identify the Common Context and to additional information to identify the Common Context and to
derive AEAD keys and Common IV. The use of ID Context is derive AEAD keys and Common IV. The use of ID Context is
described in Section 5.1. described in Section 5.1.
o Common IV. Byte string derived from Master Secret, Master Salt, o Common IV. Byte string derived from the Master Secret, Master
and ID Context. Used to generate the AEAD Nonce (see Salt, and ID Context. Used to generate the AEAD nonce (see
Section 5.2). Same length as the nonce of the AEAD Algorithm. Section 5.2). Same length as the nonce of the AEAD Algorithm.
The Sender Context contains the following parameters: The Sender Context contains the following parameters:
o Sender ID. Byte string used to identify the Sender Context, to o Sender ID. Byte string used to identify the Sender Context, to
derive AEAD keys and Common IV, and to assure unique AEAD nonces. derive AEAD keys and Common IV, and to contribute to the
Maximum length is determined by the AEAD Algorithm. uniqueness of AEAD nonces. Maximum length is determined by the
AEAD Algorithm.
o Sender Key. Byte string containing the symmetric AEAD key to o Sender Key. Byte string containing the symmetric AEAD key to
protect messages to send. Derived from Common Context and Sender protect messages to send. Derived from Common Context and Sender
ID. Length is determined by the AEAD Algorithm. ID. Length is determined by the AEAD Algorithm.
o Sender Sequence Number. Non-negative integer used by the sender o Sender Sequence Number. Non-negative integer used by the sender
to enumerate requests and certain responses, e.g. Observe to enumerate requests and certain responses, e.g., Observe
notifications. Used as 'Partial IV' [RFC8152] to generate unique notifications. Used as "Partial IV" [RFC8152] to generate unique
AEAD nonces. Maximum value is determined by the AEAD Algorithm. AEAD nonces. Maximum value is determined by the AEAD Algorithm.
Initialization is described in Section 3.2.2. Initialization is described in Section 3.2.2.
The Recipient Context contains the following parameters: The Recipient Context contains the following parameters:
o Recipient ID. Byte string used to identify the Recipient Context, o Recipient ID. Byte string used to identify the Recipient Context,
to derive AEAD keys and Common IV, and to assure unique AEAD to derive AEAD keys and Common IV, and to contribute to the
nonces. Maximum length is determined by the AEAD Algorithm. uniqueness of AEAD nonces. Maximum length is determined by the
AEAD Algorithm.
o Recipient Key. Byte string containing the symmetric AEAD key to o Recipient Key. Byte string containing the symmetric AEAD key to
verify messages received. Derived from Common Context and verify messages received. Derived from Common Context and
Recipient ID. Length is determined by the AEAD Algorithm. Recipient ID. Length is determined by the AEAD Algorithm.
o Replay Window (Server only). The replay window to verify requests o Replay Window (Server only). The replay window used to verify
received. Replay protection is described in Section 7.4 and requests received. Replay protection is described in Section 7.4
Section 3.2.2. and Section 3.2.2.
All parameters except Sender Sequence Number and Replay Window are All parameters except Sender Sequence Number and Replay Window are
immutable once the security context is established. An endpoint may immutable once the security context is established. An endpoint may
free up memory by not storing the Common IV, Sender Key, and free up memory by not storing the Common IV, Sender Key, and
Recipient Key, deriving them when needed. Alternatively, an endpoint Recipient Key, deriving them when needed. Alternatively, an endpoint
may free up memory by not storing the Master Secret and Master Salt may free up memory by not storing the Master Secret and Master Salt
after the other parameters have been derived. after the other parameters have been derived.
Endpoints MAY operate as both client and server and use the same Endpoints MAY operate as both client and server and use the same
security context for those roles. Independent of being client or security context for those roles. Independent of being client or
server, the endpoint protects messages to send using its Sender server, the endpoint protects messages to send using its Sender
Context, and verifies messages received using its Recipient Context. Context, and verifies messages received using its Recipient Context.
The endpoints MUST NOT change the Sender/Recipient ID when changing The endpoints MUST NOT change the Sender/Recipient ID when changing
roles. In other words, changing the roles does not change the set of roles. In other words, changing the roles does not change the set of
AEAD keys to be used. AEAD keys to be used.
3.2. Establishment of Security Context Parameters 3.2. Establishment of Security Context Parameters
Each endpoint derives the parameters in the security context from a Each endpoint derives the parameters in the security context from a
small set of input parameters. The following input parameters SHALL small set of input parameters. The following input parameters SHALL
be pre-established: be preestablished:
o Master Secret o Master Secret
o Sender ID o Sender ID
o Recipient ID o Recipient ID
The following input parameters MAY be pre-established. In case any The following input parameters MAY be preestablished. In case any of
of these parameters is not pre-established, the default value these parameters is not preestablished, the default value indicated
indicated below is used: below is used:
o AEAD Algorithm o AEAD Algorithm
* Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10) * Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10)
o Master Salt o Master Salt
* Default is the empty byte string * Default is the empty byte string
o HKDF Algorithm o HKDF Algorithm
* Default is HKDF SHA-256 * Default is HKDF SHA-256
o Replay Window o Replay Window
* Default is DTLS-type replay protection with a window size of 32
[RFC6347]
All input parameters need to be known to and agreed on by both * The default mechanism is an anti-replay sliding window (see
endpoints, but the replay window may be different in the two Section 4.1.2.6 of [RFC6347] with a window size of 32
endpoints. The way the input parameters are pre-established, is
All input parameters need to be known and agreed on by both
endpoints, but the Replay Window may be different in the two
endpoints. The way the input parameters are preestablished is
application specific. Considerations of security context application specific. Considerations of security context
establishment are given in Section 12.2 and examples of deploying establishment are given in Section 12.2 and examples of deploying
OSCORE in Appendix B. OSCORE 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 HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms The HKDF MUST be one of the HMAC-based HKDF [RFC5869] algorithms
defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to implement. defined for COSE [RFC8152]. HKDF SHA-256 is mandatory to implement.
The security context parameters Sender Key, Recipient Key, and Common The security context parameters Sender Key, Recipient Key, and Common
IV SHALL be derived from the input parameters using the HKDF, which IV SHALL be derived from the input parameters using the HKDF, which
skipping to change at page 11, line 32 skipping to change at page 12, line 39
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 the serialization of a CBOR array consisting of (the o info is the serialization of a CBOR array consisting of (the
notation follows Appendix E): notation follows [RFC8610] as summarized in Appendix E):
info = [ info = [
id : bstr, id : bstr,
id_context : bstr / nil, id_context : bstr / nil,
alg_aead : int / tstr, alg_aead : int / tstr,
type : tstr, type : tstr,
L : uint, L : uint,
] ]
where: where:
o id is the Sender ID or Recipient ID when deriving Sender Key and o id is the Sender ID or Recipient ID when deriving Sender Key and
Recipient Key, respectively, and the empty byte string when Recipient Key, respectively, and the empty byte string when
deriving the Common IV. deriving the Common IV.
o id_context is the ID Context, or nil if ID Context is not o id_context is the ID Context, or nil if ID Context is not
provided. provided.
o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152]. o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152].
o type is "Key" or "IV". The label is an ASCII string, and does not o type is "Key" or "IV". The label is an ASCII string and does not
include a trailing NUL byte. include a trailing NUL byte.
o L is the size of the key/nonce for the AEAD algorithm used, in o L is the size of the key/nonce for the AEAD Algorithm used, in
bytes. bytes.
For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in
[RFC8152]) is used, the integer value for alg_aead is 10, the value [RFC8152]) is used, the integer value for alg_aead is 10, the value
for L is 16 for keys and 13 for the Common IV. Assuming use of the for L is 16 for keys and 13 for the Common IV. Assuming use of the
default algorithms HKDF SHA-256 and AES-CCM-16-64-128, the extract default algorithms HKDF SHA-256 and AES-CCM-16-64-128, the extract
phase of HKDF produces a pseudorandom key (PRK) as follows: phase of HKDF produces a pseudorandom key (PRK) as follows:
PRK = HMAC-SHA-256(Master Salt, Master Secret) PRK = HMAC-SHA-256(Master Salt, Master Secret)
and as L is smaller than the hash function output size, the expand and as L is smaller than the hash function output size, the expand
phase of HKDF consists of a single HMAC invocation, and the Sender phase of HKDF consists of a single HMAC invocation; therefore, the
Key, Recipient Key, and Common IV are therefore the first 16 or 13 Sender Key, Recipient Key, and Common IV are the first 16 or 13 bytes
bytes of of
output parameter = HMAC-SHA-256(PRK, info || 0x01) output parameter = HMAC-SHA-256(PRK, info || 0x01)
where different info are used for each derived parameter and where || where different values of info are used for each derived parameter
denotes byte string concatenation. and where || denotes byte string concatenation.
Note that [RFC5869] specifies that if the salt is not provided, it is Note that [RFC5869] specifies that if the salt is not provided, it is
set to a string of zeros. For implementation purposes, not providing set to a string of zeros. For implementation purposes, not providing
the salt is the same as setting the salt to the empty byte string. the salt is the same as setting the salt to the empty byte string.
OSCORE sets the salt default value to empty byte string, which is OSCORE sets the salt default value to empty byte string, which is
converted to a string of zeroes (see Section 2.2 of [RFC5869]). converted to a string of zeroes (see Section 2.2 of [RFC5869]).
3.2.2. Initial Sequence Numbers and Replay Window 3.2.2. Initial Sequence Numbers and Replay Window
The Sender Sequence Number is initialized to 0. The Sender Sequence Number is initialized to 0.
The supported types of replay protection and replay window length is The supported types of replay protection and replay window size is
application specific and depends on how OSCORE is transported, see application specific and depends on how OSCORE is transported (see
Section 7.4. The default is DTLS-type replay protection with a Section 7.4). The default mechanism is the anti-replay window of
window size of 32 initiated as described in Section 4.1.2.6 of received messages used by IPsec AH/ESP and DTLS (see Section 4.1.2.6
[RFC6347]. of [RFC6347]) with a window size of 32.
3.3. Requirements on the Security Context Parameters 3.3. Requirements on the Security Context Parameters
To ensure unique Sender Keys, the quartet (Master Secret, Master To ensure unique Sender Keys, the quartet (Master Secret, Master
Salt, ID Context, Sender ID) MUST be unique, i.e. the pair (ID Salt, ID Context, Sender ID) MUST be unique, i.e., the pair (ID
Context, Sender ID) SHALL be unique in the set of all security Context, Sender ID) SHALL be unique in the set of all security
contexts using the same Master Secret and Master Salt. This means contexts using the same Master Secret and Master Salt. This means
that Sender ID SHALL be unique in the set of all security contexts that Sender ID SHALL be unique in the set of all security contexts
using the same Master Secret, Master Salt, and ID Context; such a using the same Master Secret, Master Salt, and ID Context; such a
requirement guarantees unique (key, nonce) pairs for the AEAD. requirement guarantees unique (key, nonce) pairs for the AEAD.
Different methods can be used to assign Sender IDs: a protocol that Different methods can be used to assign Sender IDs: a protocol that
allows the parties to negotiate locally unique identifiers, a trusted allows the parties to negotiate locally unique identifiers, a trusted
third party (e.g., [I-D.ietf-ace-oauth-authz]), or the identifiers third party (e.g., [ACE-OAuth]), or the identifiers can be assigned
can be assigned out-of-band. The Sender IDs can be very short (note out-of-band. The Sender IDs can be very short (note that the empty
that the empty string is a legitimate value). The maximum length of string is a legitimate value). The maximum length of Sender ID in
Sender ID in bytes equals the length of AEAD nonce minus 6, see bytes equals the length of the AEAD nonce minus 6, see Section 5.2.
Section 5.2. For AES-CCM-16-64-128 the maximum length of Sender ID For AES-CCM-16-64-128 the maximum length of Sender ID is 7 bytes.
is 7 bytes.
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 Common Contexts, then the endpoint may need to try multiple different Common Contexts, then the endpoint may need to try multiple
times before verifying the right security context associated to the times before verifying the right security context associated to the
Recipient ID. Recipient ID.
The ID Context is used to distinguish between security contexts. The The ID Context is used to distinguish between security contexts. The
methods used for assigning Sender ID can also be used for assigning methods used for assigning Sender ID can also be used for assigning
the ID Context. Additionally, the ID Context can be used to the ID Context. Additionally, the ID Context can be used to
introduce randomness into new Sender and Recipient Contexts (see introduce randomness into new Sender and Recipient Contexts (see
Appendix B.2). ID Context can be arbitrarily long. Appendix B.2). ID Context can be arbitrarily long.
skipping to change at page 13, line 49 skipping to change at page 15, line 24
The remainder of this section and later sections focus on the The remainder of this section and later sections focus on the
behavior in terms of CoAP messages. If HTTP is used for a particular behavior in terms of CoAP messages. If HTTP is used for a particular
hop in the end-to-end path, then this section applies to the hop in the end-to-end path, then this section applies to the
conceptual CoAP message that is mappable to/from the original HTTP conceptual CoAP message that is mappable to/from the original HTTP
message as discussed in Section 11. That is, an HTTP message is message as discussed in Section 11. That is, an HTTP message is
conceptually transformed to a CoAP message and then to an OSCORE conceptually transformed to a CoAP message and then to an OSCORE
message, and similarly in the reverse direction. An actual message, and similarly in the reverse direction. An actual
implementation might translate directly from HTTP to OSCORE without implementation might translate directly from HTTP to OSCORE without
the intervening CoAP representation. the intervening CoAP representation.
Protection of Signaling messages (Section 5 of [RFC8323]) is Protection of signaling messages (Section 5 of [RFC8323]) is
specified in Section 4.3. The other parts of this section target specified in Section 4.3. The other parts of this section target
Request/Response messages. request/response messages.
Message fields of the CoAP message may be protected end-to-end Message fields of the CoAP message may be protected end-to-end
between CoAP client and CoAP server in different ways: between CoAP client and CoAP server in different ways:
o Class E: encrypted and integrity protected, o Class E: encrypted and integrity protected,
o Class I: integrity protected only, or o Class I: integrity protected only, or
o Class U: unprotected. o Class U: unprotected.
The sending endpoint SHALL transfer Class E message fields in the The sending endpoint SHALL transfer Class E message fields in the
ciphertext of the COSE object in the OSCORE message. The sending ciphertext of the COSE object in the OSCORE message. The sending
endpoint SHALL include Class I message fields in the Additional endpoint SHALL include Class I message fields in the AAD of the AEAD
Authenticated Data (AAD) of the AEAD algorithm, allowing the algorithm, allowing the receiving endpoint to detect if the value has
receiving endpoint to detect if the value has changed in transfer. changed in transfer. Class U message fields SHALL NOT be protected
Class U message fields SHALL NOT be protected in transfer. Class I in transfer. Class I and Class U message field values are
and Class U message field values are transferred in the header or transferred in the header or options part of the OSCORE message,
options part of the OSCORE message, which is visible to proxies. which is visible to proxies.
Message fields not visible to proxies, i.e., transported in the Message fields not visible to proxies, i.e., transported in the
ciphertext of the COSE object, are called "Inner" (Class E). Message ciphertext of the COSE object, are called "Inner" (Class E). Message
fields transferred in the header or options part of the OSCORE fields transferred in the header or options part of the OSCORE
message, which is visible to proxies, are called "Outer" (Class I or message, which is visible to proxies, are called "Outer" (Class I or
U). There are currently no Class I options defined. Class 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
enable proxy operations. enable proxy operations.
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. Certain options require special are protected accordingly. Certain options require special
processing as is described in Section 4.1.3. processing as is described in Section 4.1.3.
Options that are unknown or for which OSCORE processing is not Options that are unknown or for which OSCORE processing is not
defined SHALL be processed as class E (and no special processing). defined SHALL be processed as Class E (and no special processing).
Specifications of new CoAP options SHOULD define how they are Specifications of new CoAP options SHOULD define how they are
processed with OSCORE. A new COAP option SHOULD be of class E unless processed with OSCORE. A new COAP option SHOULD be of Class E unless
it requires proxy processing. If a new CoAP option is of class U, it requires proxy processing. If a new CoAP option is of class U,
the potential issues with the option being unprotected SHOULD be the potential issues with the option being unprotected SHOULD be
documented (see Appendix D.5). documented (see Appendix D.5).
4.1.1. Inner Options 4.1.1. Inner Options
Inner option message fields (class E) are used to communicate Inner option message fields (Class E) are used to communicate
directly with the other endpoint. directly with the other endpoint.
The sending endpoint SHALL write the Inner option message fields The sending endpoint SHALL write the Inner option message fields
present in the original CoAP message into the plaintext of the COSE present in the original CoAP message into the plaintext of the COSE
object (Section 5.3), and then remove the Inner option message fields object (Section 5.3) and then remove the Inner option message fields
from the OSCORE message. from the OSCORE message.
The processing of Inner option message fields by the receiving The processing of Inner option message fields by the receiving
endpoint is specified in Sections 8.2 and 8.4. endpoint is specified in Sections 8.2 and 8.4.
+------+-----------------+---+---+ +------+-----------------+---+---+
| No. | Name | E | U | | No. | Name | E | U |
+------+-----------------+---+---+ +------+-----------------+---+---+
| 1 | If-Match | x | | | 1 | If-Match | x | |
| 3 | Uri-Host | | x | | 3 | Uri-Host | | x |
| 4 | ETag | x | | | 4 | ETag | x | |
| 5 | If-None-Match | x | | | 5 | If-None-Match | x | |
| 6 | Observe | x | x | | 6 | Observe | x | x |
| 7 | Uri-Port | | x | | 7 | Uri-Port | | x |
| 8 | Location-Path | x | | | 8 | Location-Path | x | |
| TBD1 | OSCORE | | x | | 9 | OSCORE | | x |
| 11 | Uri-Path | x | | | 11 | Uri-Path | x | |
| 12 | Content-Format | x | | | 12 | Content-Format | x | |
| 14 | Max-Age | x | x | | 14 | Max-Age | x | x |
| 15 | Uri-Query | x | | | 15 | Uri-Query | x | |
| 17 | Accept | x | | | 17 | Accept | x | |
| 20 | Location-Query | x | | | 20 | Location-Query | x | |
| 23 | Block2 | x | x | | 23 | Block2 | x | x |
| 27 | Block1 | x | x | | 27 | Block1 | x | x |
| 28 | Size2 | x | x | | 28 | Size2 | x | x |
| 35 | Proxy-Uri | | x | | 35 | Proxy-Uri | | x |
skipping to change at page 16, line 14 skipping to change at page 17, line 45
4.1.2. Outer Options 4.1.2. Outer Options
Outer option message fields (Class U or I) are used to support proxy Outer option message fields (Class U or I) are used to support proxy
operations, see Appendix D.2. operations, see Appendix D.2.
The sending endpoint SHALL include the Outer option message field The sending endpoint SHALL include the Outer option message field
present in the original message in the options part of the OSCORE present in the original message in the options part of the OSCORE
message. All Outer option message fields, including the OSCORE message. All Outer option message fields, including the OSCORE
option, SHALL be encoded as described in Section 3.1 of [RFC7252], option, SHALL be encoded as described in Section 3.1 of [RFC7252],
where the delta is the difference to the previously included instance where the delta is the difference from the previously included
of Outer option message field. instance of Outer option message field.
The processing of Outer options by the receiving endpoint is The processing of Outer options by the receiving endpoint is
specified in Sections 8.2 and 8.4. specified in Sections 8.2 and 8.4.
A procedure for integrity-protection-only of Class I option message A procedure for integrity-protection-only of Class I option message
fields is specified in Section 5.4. Specifications that introduce fields is specified in Section 5.4. Specifications that introduce
repeatable Class I options MUST specify that proxies MUST NOT change repeatable Class I options MUST specify that proxies MUST NOT change
the order of the instances of such an option in the CoAP message. the order of the instances of such an option in the CoAP message.
Note: There are currently no Class I option message fields defined. Note: There are currently no Class I option message fields defined.
skipping to change at page 16, line 46 skipping to change at page 18, line 31
option is not accessible to proxies. The Inner Max-Age SHALL be option is not accessible to proxies. The Inner Max-Age SHALL be
processed by OSCORE as a normal Inner option, specified in processed by OSCORE as a normal Inner option, specified in
Section 4.1.1. Section 4.1.1.
An Outer Max-Age message field is used to avoid unnecessary caching An Outer Max-Age message field is used to avoid unnecessary caching
of error responses caused by OSCORE processing at OSCORE-unaware of error responses caused by OSCORE processing at OSCORE-unaware
intermediary nodes. A server MAY set a Class U Max-Age message field intermediary nodes. A server MAY set a Class U Max-Age message field
with value zero to such error responses, described in Sections 7.4, with value zero to such error responses, described in Sections 7.4,
8.2, and 8.4, since these error responses are cacheable, but 8.2, and 8.4, since these error responses are cacheable, but
subsequent OSCORE requests would never create a hit in the subsequent OSCORE requests would never create a hit in the
intermediary caching it. Setting the Outer Max-Age to zero relieves intermediary node caching it. Setting the Outer Max-Age to zero
the intermediary from uselessly caching responses. Successful OSCORE relieves the intermediary from uselessly caching responses.
responses do not need to include an Outer Max-Age option since the Successful OSCORE responses do not need to include an Outer Max-Age
responses appear to the OSCORE-unaware intermediary as 2.04 (Changed) option. Except when the Observe option (see Section 4.1.3.5) is
responses, which are non-cacheable (see Section 4.2). used, responses appear to the OSCORE-unaware intermediary as 2.04
(Changed) responses, which are non-cacheable (see Section 4.2). For
Observe responses, which are cacheable, an Outer Max-Age option with
value 0 may be used to avoid unnecessary proxy caching.
The Outer Max-Age message field is processed according to The Outer Max-Age message field is processed according to
Section 4.1.2. Section 4.1.2.
4.1.3.2. Uri-Host and Uri-Port 4.1.3.2. Uri-Host and Uri-Port
When the Uri-Host and Uri-Port are set to their default values (see When the Uri-Host and Uri-Port are set to their default values (see
Section 5.10.1 [RFC7252]), they are omitted from the message Section 5.10.1 [RFC7252]), they are omitted from the message
(Section 5.4.4 of [RFC7252]), which is favorable both for overhead (Section 5.4.4 of [RFC7252]), which is favorable both for overhead
and privacy. and privacy.
skipping to change at page 17, line 31 skipping to change at page 19, line 17
OSCORE message becoming verified by an unintended server. Different OSCORE message becoming verified by an unintended server. Different
servers SHALL have different security contexts. servers SHALL have different security contexts.
4.1.3.3. Proxy-Uri 4.1.3.3. Proxy-Uri
When Proxy-Uri is present, the client SHALL first decompose the When Proxy-Uri is present, the client SHALL first decompose the
Proxy-Uri value of the original CoAP message into the Proxy-Scheme, Proxy-Uri value of the original CoAP message into the Proxy-Scheme,
Uri-Host, Uri-Port, Uri-Path, and Uri-Query options according to Uri-Host, Uri-Port, Uri-Path, and Uri-Query options according to
Section 6.4 of [RFC7252]. Section 6.4 of [RFC7252].
Uri-Path and Uri-Query are class E options and SHALL be protected and Uri-Path and Uri-Query are Class E options and SHALL be protected and
processed as Inner options (Section 4.1.1). processed as Inner options (Section 4.1.1).
The Proxy-Uri option of the OSCORE message SHALL be set to the The Proxy-Uri option of the OSCORE message SHALL be set to the
composition of Proxy-Scheme, Uri-Host, and Uri-Port options as composition of Proxy-Scheme, Uri-Host, and Uri-Port options as
specified in Section 6.5 of [RFC7252], and processed as an Outer specified in Section 6.5 of [RFC7252] and processed as an Outer
option of Class U (Section 4.1.2). option of Class U (Section 4.1.2).
Note that replacing the Proxy-Uri value with the Proxy-Scheme and Note that replacing the Proxy-Uri value with the Proxy-Scheme and
Uri-* options works by design for all CoAP URIs (see Section 6 of Uri-* options works by design for all CoAP URIs (see Section 6 of
[RFC7252]). OSCORE-aware HTTP servers should not use the userinfo [RFC7252]). OSCORE-aware HTTP servers should not use the userinfo
component of the HTTP URI (as defined in Section 3.2.1 of [RFC3986]), component of the HTTP URI (as defined in Section 3.2.1 of [RFC3986]),
so that this type of replacement is possible in the presence of CoAP- so that this type of replacement is possible in the presence of CoAP-
to-HTTP proxies (see Section 11.2). In future specifications of to-HTTP proxies (see Section 11.2). In future specifications of
cross-protocol proxying behavior using different URI structures, it cross-protocol proxying behavior using different URI structures, it
is expected that the authors will create Uri-* options that allow is expected that the authors will create Uri-* options that allow
skipping to change at page 18, line 4 skipping to change at page 19, line 39
so that this type of replacement is possible in the presence of CoAP- so that this type of replacement is possible in the presence of CoAP-
to-HTTP proxies (see Section 11.2). In future specifications of to-HTTP proxies (see Section 11.2). In future specifications of
cross-protocol proxying behavior using different URI structures, it cross-protocol proxying behavior using different URI structures, it
is expected that the authors will create Uri-* options that allow is expected that the authors will create Uri-* options that allow
decomposing the Proxy-Uri, and specifying the OSCORE processing. decomposing the Proxy-Uri, and specifying the OSCORE processing.
An example of how Proxy-Uri is processed is given here. Assume that An example of how Proxy-Uri is processed is given here. Assume that
the original CoAP message contains: the original CoAP message contains:
o Proxy-Uri = "coap://example.com/resource?q=1" o Proxy-Uri = "coap://example.com/resource?q=1"
During OSCORE processing, Proxy-Uri is split into: During OSCORE processing, Proxy-Uri is split into:
o Proxy-Scheme = "coap" o Proxy-Scheme = "coap"
o Uri-Host = "example.com" o Uri-Host = "example.com"
o Uri-Port = "5683" o Uri-Port = "5683" (default)
o Uri-Path = "resource" o Uri-Path = "resource"
o Uri-Query = "q=1" o Uri-Query = "q=1"
Uri-Path and Uri-Query follow the processing defined in Uri-Path and Uri-Query follow the processing defined in
Section 4.1.1, and are thus encrypted and transported in the COSE Section 4.1.1; thus, they are encrypted and transported in the COSE
object: object:
o Uri-Path = "resource" o Uri-Path = "resource"
o Uri-Query = "q=1" o Uri-Query = "q=1"
The remaining options are composed into the Proxy-Uri included in the The remaining options are composed into the Proxy-Uri included in the
options part of the OSCORE message, which has value: options part of the OSCORE message, which has value:
o Proxy-Uri = "coap://example.com" o Proxy-Uri = "coap://example.com"
See Sections 6.1 and 12.6 of [RFC7252] for more details. See Sections 6.1 and 12.6 of [RFC7252] for more details.
4.1.3.4. The Block Options 4.1.3.4. The Block Options
Block-wise [RFC7959] is an optional feature. An implementation MAY Block-wise [RFC7959] is an optional feature. An implementation MAY
support [RFC7252] and the OSCORE option without supporting block-wise support CoAP [RFC7252] and the OSCORE option without supporting
transfers. The Block options (Block1, Block2, Size1, Size2), when block-wise transfers. The Block options (Block1, Block2, Size1,
Inner message fields, provide secure message segmentation such that Size2), when Inner message fields, provide secure message
each segment 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, enable 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 Block-wise transfers provided all blocks are received. both in case of Inner and Outer Block-wise transfers, provided all
blocks are received.
4.1.3.4.1. Inner Block Options 4.1.3.4.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 normal Inner the Block options SHALL be processed by OSCORE as normal Inner
options (Section 4.1.1). The receiving CoAP endpoint SHALL process options (Section 4.1.1). The receiving CoAP endpoint SHALL process
the OSCORE message before processing Block-wise as defined in the OSCORE message before processing Block-wise as defined in
[RFC7959]. [RFC7959].
4.1.3.4.2. Outer Block Options 4.1.3.4.2. Outer Block Options
Proxies MAY fragment an OSCORE message using [RFC7959], by Proxies MAY fragment an OSCORE message using [RFC7959] by introducing
introducing Block option message fields that are Outer Block option message fields that are Outer (Section 4.1.2). Note
(Section 4.1.2). Note that the Outer Block options are neither that the Outer Block options are neither encrypted nor integrity
encrypted nor integrity protected. As a consequence, a proxy can protected. As a consequence, a proxy can maliciously inject block
maliciously inject block fragments indefinitely, since the receiving fragments indefinitely, since the receiving endpoint needs to receive
endpoint needs to receive the last block (see [RFC7959]) to be able the last block (see [RFC7959]) to be able to compose the OSCORE
to compose the OSCORE message and verify its integrity. Therefore, message and verify its integrity. Therefore, applications supporting
applications supporting OSCORE and [RFC7959] MUST specify a security OSCORE and [RFC7959] MUST specify a security policy defining a
policy defining a maximum unfragmented message size maximum unfragmented message size (MAX_UNFRAGMENTED_SIZE) considering
(MAX_UNFRAGMENTED_SIZE) considering the maximum size of message which the maximum size of message that can be handled by the endpoints.
can be handled by the endpoints. Messages exceeding this size SHOULD Messages exceeding this size SHOULD be fragmented by the sending
be fragmented by the sending endpoint using Inner Block options endpoint using Inner Block options (Section 4.1.3.4.1).
(Section 4.1.3.4.1).
An endpoint receiving an OSCORE message with an Outer Block option An endpoint receiving an OSCORE message with an Outer Block option
SHALL first process this option according to [RFC7959], until all SHALL first process this option according to [RFC7959], until all
blocks of the OSCORE message have been received, or the cumulated blocks of the OSCORE message have been received or the cumulated
message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE. In the message size of the blocks exceeds MAX_UNFRAGMENTED_SIZE. In the
former case, the processing of the OSCORE message continues as former case, the processing of the OSCORE message continues as
defined in this document. In the latter case the message SHALL be defined in this document. In the latter case, the message SHALL be
discarded. discarded.
Because of encryption of Uri-Path and Uri-Query, messages to the same Because of encryption of Uri-Path and Uri-Query, messages to the same
server may, from the point of view of a proxy, look like they also server may, from the point of view of a proxy, look like they also
target the same resource. A proxy SHOULD mitigate a potential mix-up target the same resource. A proxy SHOULD mitigate a potential mix-up
of blocks from concurrent requests to the same server, for example of blocks from concurrent requests to the same server, for example,
using the Request-Tag processing specified in Section 3.3.2 of using the Request-Tag processing specified in Section 3.3.2 of
[I-D.ietf-core-echo-request-tag]. [CoAP-ECHO-REQ-TAG].
4.1.3.5. Observe 4.1.3.5. Observe
Observe [RFC7641] is an optional feature. An implementation MAY Observe [RFC7641] is an optional feature. An implementation MAY
support [RFC7252] and the OSCORE option without supporting [RFC7641], support CoAP [RFC7252] and the OSCORE option without supporting
in which case the Observe related processing can be omitted. [RFC7641], in which case the Observe-related processing can be
omitted.
The support for Observe [RFC7641] with OSCORE targets the The support for Observe [RFC7641] with OSCORE targets the
requirements on forwarding of Section 2.2.1 of requirements on forwarding of Section 2.2.1 of [CoAP-E2E-Sec], i.e.,
[I-D.hartke-core-e2e-security-reqs], i.e. that observations go that observations go through intermediary nodes, as illustrated in
through intermediary nodes, as illustrated in Figure 8 of [RFC7641]. Figure 8 of [RFC7641].
Inner Observe SHALL be used to protect the value of the Observe Inner Observe SHALL be used to protect the value of the Observe
option between the endpoints. Outer Observe SHALL be used to support option between the endpoints. Outer Observe SHALL be used to support
forwarding by intermediary nodes. forwarding by intermediary nodes.
The server SHALL include a new Partial IV (see Section 5) in The server SHALL include a new Partial IV (see Section 5) in
responses (with or without the Observe option) to Observe responses (with or without the Observe option) to Observe
registrations, except for the first response where Partial IV MAY be registrations, except for the first response where Partial IV MAY be
omitted. omitted.
For cancellations, Section 3.6 of [RFC7641] specifies that all For cancellations, Section 3.6 of [RFC7641] specifies that all
options MUST be identical to those in the registration request except options MUST be identical to those in the registration request except
for Observe and the set of ETag Options. For OSCORE messages, this for the Observe option and the set of ETag options. For OSCORE
matching is to be done to the options in the decrypted message. messages, this matching is to be done to the options in the decrypted
message.
[RFC7252] does not specify how the server should act upon receiving [RFC7252] does not specify how the server should act upon receiving
the same Token in different requests. When using OSCORE, the server the same Token in different requests. When using OSCORE, the server
SHOULD NOT remove an active observation just because it receives a SHOULD NOT remove an active observation just because it receives a
request with the same Token. request with the same Token.
Since POST with Observe is not defined, for messages with Observe, Since POST with the Observe option is not defined, for messages with
the Outer Code MUST be set to 0.05 (FETCH) for requests and to 2.05 the Observe option, the Outer Code MUST be set to 0.05 (FETCH) for
(Content) for responses (see Section 4.2). requests and to 2.05 (Content) for responses (see Section 4.2).
4.1.3.5.1. Registrations and Cancellations 4.1.3.5.1. Registrations and Cancellations
The Inner and Outer Observe in the request MUST contain the Observe The Inner and Outer Observe options in the request MUST contain the
value of the original CoAP request; 0 (registration) or 1 Observe value of the original CoAP request; 0 (registration) or 1
(cancellation). (cancellation).
Every time a client issues a new Observe request, a new Partial IV Every time a client issues a new request with the Observe option, a
MUST be used (see Section 5), and so the payload and OSCORE option new Partial IV MUST be used (see Section 5), and so the payload and
are changed. The server uses the Partial IV of the new request as OSCORE option are changed. The server uses the Partial IV of the new
the 'request_piv' of all associated notifications (see Section 5.4). request as the 'request_piv' of all associated notifications (see
Section 5.4).
Intermediaries are not assumed to have access to the OSCORE security Intermediaries are not assumed to have access to the OSCORE security
context used by the endpoints, and thus cannot make requests or context used by the endpoints; thus, they cannot make requests or
transform responses with the OSCORE option which verify at the transform responses with the OSCORE option that pass verification (at
receiving endpoint as coming from the other endpoint. This has the the receiving endpoint) as having come from the other endpoint. This
following consequences and limitations for Observe operations. has the following consequences and limitations for Observe
operations.
o An intermediary node removing the Outer Observe 0 does not change o An intermediary node removing the Outer Observe 0 option does not
the registration request to a request without Observe (see change the registration request to a request without the Observe
Section 2 of [RFC7641]). Instead other means for cancellation may option (see Section 2 of [RFC7641]). Instead other means for
be used as described in Section 3.6 of [RFC7641]. cancellation may be used as described in Section 3.6 of [RFC7641].
o An intermediary node is not able to transform a normal response o An intermediary node is not able to transform a normal response
into an OSCORE protected Observe notification (see figure 7 of into an OSCORE-protected Observe notification (see Figure 7 of
[RFC7641]) which verifies as coming from the server. [RFC7641]) that verifies as coming from the server.
o An intermediary node is not able to initiate an OSCORE protected o An intermediary node is not able to initiate an OSCORE protected
Observe registration (Observe with value 0) which verifies as Observe registration (Observe option with value 0) that verifies
coming from the client. An OSCORE-aware intermediary SHALL NOT as coming from the client. An OSCORE-aware intermediary SHALL NOT
initiate registrations of observations (see Section 10). If an initiate registrations of observations (see Section 10). If an
OSCORE-unaware proxy re-sends an old registration message from a OSCORE-unaware proxy resends an old registration message from a
client this will trigger the replay protection mechanism in the client, the replay protection mechanism in the server will be
server. To prevent this from resulting in the OSCORE-unaware triggered. To prevent this from resulting in the OSCORE-unaware
proxy to cancel of the registration, a server MAY respond to a proxy canceling the registration, a server MAY respond to a
replayed registration request with a replay of a cached replayed registration request with a replay of a cached
notification. Alternatively, the server MAY send a new notification. Alternatively, the server MAY send a new
notification. notification.
o An intermediary node is not able to initiate an OSCORE protected o An intermediary node is not able to initiate an OSCORE-protected
Observe cancellation (Observe with value 1) which verifies as Observe cancellation (Observe option with value 1) that verifies
coming from the client. An application MAY decide to allow as coming from the client. An application MAY decide to allow
intermediaries to cancel Observe registrations, e.g. to send intermediaries to cancel Observe registrations, e.g., to send the
Observe with value 1 (see Section 3.6 of [RFC7641]), but that can Observe option with value 1 (see Section 3.6 of [RFC7641]);
also be done with other methods, e.g. reusing the Token in a however, that can also be done with other methods, e.g., by
different request or sending a RST message. This is out of scope sending a RST message. This is out of scope for this
for this specification. specification.
4.1.3.5.2. Notifications 4.1.3.5.2. Notifications
If the server accepts an Observe registration, a Partial IV MUST be If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error), except for included in all notifications (both successful and error), except for
the first one where Partial IV MAY be omitted. To protect against the first one where the Partial IV MAY be omitted. To protect
replay, the client SHALL maintain a Notification Number for each against replay, the client SHALL maintain a Notification Number for
Observation it registers. The Notification Number is a non-negative each Observation it registers. The Notification Number is a non-
integer containing the largest Partial IV of the received negative integer containing the largest Partial IV of the received
notifications for the associated Observe registration. Further notifications for the associated Observe registration. Further
details of replay protection of notifications are specified in details of replay protection of notifications are specified in
Section 7.4.1. Section 7.4.1.
For notifications, the Inner Observe value MUST be empty (see For notifications, the Inner Observe option value MUST be empty (see
Section 3.2 of [RFC7252]). The Outer Observe in a notification is Section 3.2 of [RFC7252]). The Outer Observe option in a
needed for intermediary nodes to allow multiple responses to one notification is needed for intermediary nodes to allow multiple
request, and may be set to the value of Observe in the original CoAP responses to one request, and it MAY be set to the value of the
message. The client performs ordering of notifications and replay Observe option in the original CoAP message. The client performs
protection by comparing their Partial IVs and SHALL ignore the outer ordering of notifications and replay protection by comparing their
Observe value. Partial IVs and SHALL ignore the Outer Observe option value.
If the client receives a response to an Observe request without an If the client receives a response to an Observe request without an
Inner Observe option, then it verifies the response as a non-Observe Inner Observe option, then it verifies the response as a non-Observe
response, as specified in Section 8.4. If the client receives a response, as specified in Section 8.4. If the client receives a
response to a non-Observe request with an Inner Observe option, then response to a non-Observe request with an Inner Observe option, then
it stops processing the message, as specified in Section 8.4. it stops processing the message, as specified in Section 8.4.
A client MUST consider the notification with the highest Partial IV A client MUST consider the notification with the highest Partial IV
as the freshest, regardless of the order of arrival. In order to as the freshest, regardless of the order of arrival. In order to
support existing Observe implementations the OSCORE client support existing Observe implementations, the OSCORE client
implementation MAY set the Observe value to the three least implementation MAY set the Observe option value to the three least
significant bytes of the Partial IV. Implementations need to make significant bytes of the Partial IV. Implementations need to make
sure that the notification without Partial IV is considered the sure that the notification without Partial IV is considered the
oldest. oldest.
4.1.3.6. No-Response 4.1.3.6. No-Response
No-Response [RFC7967] is an optional feature used by the client to No-Response [RFC7967] is an optional feature used by the client to
communicate its disinterest in certain classes of responses to a communicate its disinterest in certain classes of responses to a
particular request. An implementation MAY support [RFC7252] and the particular request. An implementation MAY support [RFC7252] and the
OSCORE option without supporting [RFC7967]. OSCORE option without supporting [RFC7967].
If used, No-Response MUST be Inner. The Inner No-Response SHALL be If used, No-Response MUST be Inner. The Inner No-Response SHALL be
processed by OSCORE as specified in Section 4.1.1. The Outer option processed by OSCORE as specified in Section 4.1.1. The Outer option
SHOULD NOT be present. The server SHALL ignore the Outer No-Response SHOULD NOT be present. The server SHALL ignore the Outer No-Response
option. The client MAY set the Outer No-Response value to 26 option. The client MAY set the Outer No-Response value to 26
('suppress all known codes') if the Inner value is set to 26. The (suppress all known codes) if the Inner value is set to 26. The
client MUST be prepared to receive and discard 5.04 (Gateway Timeout) client MUST be prepared to receive and discard 5.04 (Gateway Timeout)
error messages from intermediaries potentially resulting from error messages from intermediaries potentially resulting from
destination time out due to no response. destination time out due to no response.
4.1.3.7. OSCORE 4.1.3.7. OSCORE
The OSCORE option is only defined to be present in OSCORE messages, The OSCORE option is only defined to be present in OSCORE messages as
as an indication that OSCORE processing have been performed. The an indication that OSCORE processing has been performed. The content
content in the OSCORE option is neither encrypted nor integrity in the OSCORE option is neither encrypted nor integrity protected as
protected as a whole but some part of the content of this option is a whole, but some part of the content of this option is protected
protected (see Section 5.4). Nested use of OSCORE is not supported: (see Section 5.4). Nested use of OSCORE is not supported: If OSCORE
If OSCORE processing detects an OSCORE option in the original CoAP processing detects an OSCORE option in the original CoAP message,
message, then processing SHALL be stopped. then processing SHALL be stopped.
4.2. CoAP Header Fields and Payload
A summary of how the CoAP header fields and payload are protected is
shown in Figure 6, including fields specific to CoAP over UDP and
CoAP over TCP (marked accordingly in the table).
+------------------+---+---+ +------------------+---+---+
| Field | E | U | | Field | E | U |
+------------------+---+---+ +------------------+---+---+
| Version (UDP) | | x | | Version (UDP) | | x |
| Type (UDP) | | x | | Type (UDP) | | x |
| Length (TCP) | | x | | Length (TCP) | | x |
| Token Length | | x | | Token Length | | x |
| Code | x | | | Code | x | |
| Message ID (UDP) | | x | | Message ID (UDP) | | x |
skipping to change at page 22, line 45 skipping to change at page 24, line 49
+------------------+---+---+ +------------------+---+---+
| Version (UDP) | | x | | Version (UDP) | | x |
| Type (UDP) | | x | | Type (UDP) | | x |
| Length (TCP) | | x | | Length (TCP) | | x |
| Token Length | | x | | Token Length | | x |
| Code | x | | | Code | x | |
| Message ID (UDP) | | x | | Message ID (UDP) | | x |
| Token | | x | | Token | | x |
| Payload | x | | | Payload | x | |
+------------------+---+---+ +------------------+---+---+
E = Encrypt and Integrity Protect (Inner) E = Encrypt and Integrity Protect (Inner)
U = Unprotected (Outer) U = Unprotected (Outer)
Figure 6: Protection of CoAP Header Fields and Payload Figure 6: Protection of CoAP Header Fields and Payload
4.2. CoAP Header Fields and Payload 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; thus,
A summary of how the CoAP header fields and payload are protected is they cannot, in general, be protected end-to-end from one endpoint to
shown in Figure 6, including fields specific to CoAP over UDP and the other. As mentioned in Section 1, OSCORE protects the CoAP
CoAP over TCP (marked accordingly in the table). request/response layer only and not the CoAP messaging layer
(Section 2 of [RFC7252]), so fields such as Type and Message ID are
Most CoAP Header fields (i.e. the message fields in the fixed 4-byte not protected with OSCORE.
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.
As mentioned in Section 1, OSCORE protects the CoAP Request/Response
Layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
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 on or manipulating the Code (e.g., intermediary from eavesdropping on or manipulating it (e.g., changing
changing from GET to DELETE). 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 sending endpoint writes an Outer Code to the OSCORE After that, the sending endpoint writes an Outer Code to the OSCORE
message. With one exception (see Section 4.1.3.5) the Outer Code message. With one exception (see Section 4.1.3.5), the Outer Code
SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for SHALL be set to 0.02 (POST) for requests and to 2.04 (Changed) for
responses. The receiving endpoint SHALL discard the Outer Code in responses. The receiving endpoint SHALL discard the Outer Code in
the OSCORE message and write the Code of the COSE object plaintext the OSCORE message and write the Code of the COSE object plaintext
(Section 5.3) into the decrypted CoAP message. (Section 5.3) 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.
The CoAP Payload, if present in the original CoAP message, SHALL be The CoAP Payload, if present in the original CoAP message, SHALL be
encrypted and integrity protected and is thus an Inner message field. encrypted and integrity protected; thus, it is an Inner message
The sending endpoint writes the payload of the original CoAP message field. The sending endpoint writes the payload of the original CoAP
into the plaintext (Section 5.3) input to the COSE object. The message into the plaintext (Section 5.3) input to the COSE object.
receiving endpoint verifies and decrypts the COSE object, and The receiving endpoint verifies and decrypts the COSE object, and it
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]. specific case of CoAP over reliable transports [RFC8323].
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 signaling message. If OSCORE is coincide with the endpoints for the signaling message. If OSCORE is
used to protect Signaling then: used to protect signaling then:
o To comply with [RFC8323], an initial empty CSM message SHALL be o To comply with [RFC8323], an initial empty Capabilities and
sent. The subsequent signaling message SHALL be protected. Settings Message (CSM) 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 in which the signaling message is a response to
previous Signaling message, in which case it SHALL be protected as a previous signaling message; then it SHALL be protected as a CoAP
a CoAP Response message. For example, 7.02 (Ping) is protected as response message. For example, 7.02 (Ping) is protected as a CoAP
a CoAP Request and 7.03 (Pong) as a CoAP response. 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).
o All Signaling options, except the OSCORE option, SHALL be Inner o All signaling options, except the OSCORE option, SHALL be Inner
(Class E). (Class E).
NOTE: Option numbers for Signaling messages are specific to the CoAP NOTE: Option numbers for signaling messages are specific to the CoAP
Code (see Section 5.2 of [RFC8323]). Code (see Section 5.2 of [RFC8323]).
If OSCORE is not used to protect Signaling, Signaling messages SHALL If OSCORE is not used to protect signaling, Signaling messages SHALL
be unaltered by OSCORE. be unaltered by OSCORE.
5. The COSE Object 5. The COSE Object
This section defines how to use COSE [RFC8152] to wrap and protect This section defines how to use COSE [RFC8152] to wrap and protect
data in the original message. OSCORE uses the untagged COSE_Encrypt0 data in the original message. OSCORE uses the untagged COSE_Encrypt0
structure with an Authenticated Encryption with Additional Data structure (see Section 5.2 of [RFC8152]) with an AEAD algorithm. The
(AEAD) algorithm. The AEAD key lengths, AEAD nonce length, and AEAD key lengths, AEAD nonce length, and maximum Sender Sequence
maximum Sender Sequence Number are algorithm dependent. Number are algorithm dependent.
The AEAD algorithm AES-CCM-16-64-128 defined in Section 10.2 of The AEAD algorithm AES-CCM-16-64-128 defined in Section 10.2 of
[RFC8152] is mandatory to implement. For AES-CCM-16-64-128 the [RFC8152] is mandatory to implement. For AES-CCM-16-64-128, the
length of Sender Key and Recipient Key is 128 bits, the length of length of Sender Key and Recipient Key is 128 bits; the length of
AEAD nonce and Common IV is 13 bytes. The maximum Sender Sequence AEAD nonce and Common IV is 13 bytes. The maximum Sender Sequence
Number is specified in Section 12. Number is specified in Section 12.
As specified in [RFC5116], plaintext denotes the data that is to be As specified in [RFC5116], plaintext denotes the data that is to be
encrypted and integrity protected, and Additional Authenticated Data encrypted and integrity protected, and Additional Authenticated Data
(AAD) denotes the data that is to be integrity protected only. (AAD) denotes the data that is to be integrity protected only.
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 bytes of value zero SHALL be Sequence Number. All leading bytes of value zero SHALL be
removed when encoding the Partial IV, except in the case of removed when encoding the Partial IV, except in the case of
Partial IV of value 0 which is encoded to the byte string 0x00. Partial IV value 0, which is encoded to the byte string 0x00.
This parameter SHALL be present in requests. The Partial IV
SHALL be present in responses to Observe registrations (see This parameter SHALL be present in requests and will not
Section 4.1.3.5.1), otherwise the Partial IV will not typically typically be present in responses (for two exceptions, see
be present in responses (for one exception, see Observe notifications (Section 4.1.3.5.2) and Replay Window
Appendix B.1.2). synchronization (Appendix B.1.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 [Group-OSCORE].
* Optionally, a 'kid context' parameter (see Section 5.1). This * Optionally, a 'kid context' parameter (see Section 5.1). This
parameter MAY be present in requests, and if so, MUST contain parameter MAY be present in requests and, if so, MUST contain
an ID Context (see Section 3.1). This parameter SHOULD NOT be an ID Context (see Section 3.1). This parameter SHOULD NOT be
present in responses: an example of how 'kid context' can be present in responses: an example of how 'kid context' can be
used in responses is given in Appendix B.2. If 'kid context' used in responses is given in Appendix B.2. If 'kid context'
is present in the request, then the server SHALL use a security is present in the request, then the server SHALL use a security
context with that ID Context when verifying the request. context with that ID Context when verifying the request.
o The 'ciphertext' field is computed from the secret key (Sender Key o The 'ciphertext' field is computed from the secret key (Sender Key
or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see
Section 5.3), and the Additional Authenticated Data (AAD) (see Section 5.3), and the AAD (see Section 5.4) following Section 5.2
Section 5.4) following Section 5.2 of [RFC8152]. of [RFC8152].
The encryption process is described in Section 5.3 of [RFC8152]. The encryption process is described in Section 5.3 of [RFC8152].
5.1. ID Context and 'kid context' 5.1. ID Context and 'kid context'
For certain use cases, e.g. deployments where the same Sender ID is For certain use cases, e.g., deployments where the same Sender ID is
used with multiple contexts, it is possible (and sometimes necessary, used with multiple contexts, it is possible (and sometimes necessary,
see Section 3.3) for the client to use an ID Context to distinguish see Section 3.3) for the client to use an ID Context to distinguish
the security contexts (see Section 3.1). For example: the security contexts (see Section 3.1). For example:
o If the client has a unique identifier in some namespace then that o If the client has a unique identifier in some namespace, then that
identifier can be used as ID Context. identifier can be used as ID Context.
o The ID Context may be used to add randomness into new Sender and o The ID Context may be used to add randomness into new Sender and
Recipient Contexts, see Appendix B.2. Recipient Contexts, see Appendix B.2.
o In case of group communication [I-D.ietf-core-oscore-groupcomm], a o In the case of group communication [Group-OSCORE], a group
group identifier is used as ID Context to enable different identifier is used as ID Context to enable different security
security contexts for a server belonging to multiple groups. contexts for a server belonging to multiple groups.
The Sender ID and ID Context are used to establish the necessary The Sender ID and ID Context are used to establish the necessary
input parameters and in the derivation of the security context (see input parameters and in the derivation of the security context (see
Section 3.2). Section 3.2).
Whereas the 'kid' parameter is used to transport the Sender ID, the While the 'kid' parameter is used to transport the Sender ID, the new
new COSE header parameter 'kid context' is used to transport the ID COSE header parameter 'kid context' is used to transport the ID
Context in requests, see Figure 7. Context in requests, see Figure 7.
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
| name | label | value type | value registry | description | | Name | Label | Value Type | Value Registry | Description |
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
| kid | TBD2 | bstr | | Identifies the | | kid | 10 | bstr | | Identifies the |
| context | | | | context for kid | | context | | | | context for the |
| | | | | key identifier |
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
Figure 7: Common Header Parameter 'kid context' for the COSE object Figure 7: Common Header Parameter 'kid context' for the COSE Object
If ID Context is non-empty and the client sends a request without If ID Context is non-empty and the client sends a request without
'kid context' which results in an error indicating that the server 'kid context' resulting in an error indicating that the server could
could not find the security context, then the client could include not find the security context, then the client could include the ID
the ID Context in the 'kid context' when making another request. Context in the 'kid context' when making another request. Note that
Note that since the error is unprotected it may have been spoofed and since the error is unprotected, it may have been spoofed and the real
the real response blocked by an on-path attacker. response blocked by an on-path attacker.
5.2. AEAD Nonce 5.2. AEAD Nonce
The high level design of the AEAD nonce follows Section 4.4 of The high-level design of the AEAD nonce follows Section 4.4 of
[I-D.mcgrew-iv-gen], here follows the detailed construction (see [IV-GEN]. The detailed construction of the AEAD nonce is presented
Figure 8): here (see Figure 8):
1. left-pad the Partial IV (PIV) with zeroes to exactly 5 bytes, 1. left-pad the Partial IV (PIV) with zeroes to exactly 5 bytes,
2. left-pad the Sender ID of the endpoint that generated the Partial 2. left-pad the Sender ID of the endpoint that generated the Partial
IV (ID_PIV) with zeroes to exactly nonce length minus 6 bytes, IV (ID_PIV) with zeroes to exactly nonce length minus 6 bytes,
3. concatenate the size of the ID_PIV (a single byte S) with the 3. concatenate the size of the ID_PIV (a single byte S) with the
padded ID_PIV and the padded PIV, padded ID_PIV and the padded PIV,
4. and then XOR with the Common IV. 4. and then XOR with the Common IV.
Note that in this specification only AEAD algorithms that use nonces Note that in this specification, only AEAD algorithms that use nonces
equal or greater than 7 bytes are supported. The nonce construction equal or greater than 7 bytes are supported. The nonce construction
with S, ID_PIV, and PIV together with endpoint unique IDs and with S, ID_PIV, and PIV together with endpoint-unique IDs and
encryption keys makes it easy to verify that the nonces used with a encryption keys makes it easy to verify that the nonces used with a
specific key will be unique, see Appendix D.4. specific key will be unique, see Appendix D.4.
If the Partial IV is not present in a response, the nonce from the If the Partial IV is not present in a response, the nonce from the
request is used. For responses that are not notifications (i.e. when request is used. For responses that are not notifications (i.e.,
there is a single response to a request), the request and the when there is a single response to a request), the request and the
response should typically use the same nonce to reduce message response should typically use the same nonce to reduce message
overhead. Both alternatives provide all the required security overhead. Both alternatives provide all the required security
properties, see Section 7.4 and Appendix D.4. The only non-Observe properties, see Section 7.4 and Appendix D.4. Another non-Observe
scenario where a Partial IV must be included in a response is when scenario where a Partial IV is included in a response is when the
the server is unable to perform replay protection, see server is unable to perform replay protection, see Appendix B.1.2.
Appendix B.1.2. For processing instructions see Section 8. For processing instructions see Section 8.
<- nonce length minus 6 B -> <-- 5 bytes --> <- nonce length minus 6 B -> <-- 5 bytes -->
+---+-------------------+--------+---------+-----+ +---+-------------------+--------+---------+-----+
| S | padding | ID_PIV | padding | PIV |----+ | S | padding | ID_PIV | padding | PIV |----+
+---+-------------------+--------+---------+-----+ | +---+-------------------+--------+---------+-----+ |
| |
<---------------- nonce length ----------------> | <---------------- nonce length ----------------> |
+------------------------------------------------+ | +------------------------------------------------+ |
| Common IV |->(XOR) | Common IV |->(XOR)
+------------------------------------------------+ | +------------------------------------------------+ |
| |
<---------------- nonce length ----------------> | <---------------- nonce length ----------------> |
+------------------------------------------------+ | +------------------------------------------------+ |
| Nonce |<---+ | Nonce |<---+
+------------------------------------------------+ +------------------------------------------------+
Figure 8: AEAD Nonce Formation Figure 8: AEAD Nonce Formation
5.3. Plaintext 5.3. Plaintext
The plaintext is formatted as a CoAP message without Header (see The plaintext is formatted as a CoAP message with a subset of the
Figure 9) consisting of: header (see Figure 9) consisting of:
o the Code of the original CoAP message as defined in Section 3 of o the Code of the original CoAP message as defined in Section 3 of
[RFC7252]; and [RFC7252]; and
o all Inner option message fields (see Section 4.1.1) present in the o all Inner option message fields (see Section 4.1.1) present in the
original CoAP message (see Section 4.1). The options are encoded original CoAP message (see Section 4.1). The options are encoded
as described in Section 3.1 of [RFC7252], where the delta is the as described in Section 3.1 of [RFC7252], where the delta is the
difference to the previously included instance of Class E option; difference from the previously included instance of Class E
and option; and
o the Payload of original CoAP message, if present, and in that case o the Payload of original CoAP message, if present, and in that case
prefixed by the one-byte Payload Marker (0xff). prefixed by the one-byte Payload Marker (0xff).
NOTE: The plaintext contains all CoAP data that needs to be encrypted NOTE: The plaintext contains all CoAP data that needs to be encrypted
end-to-end between the endpoints. end-to-end between the endpoints.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Class E options (if any) ... | Code | Class E options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ... |1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(only if there (only if there is payload)
is payload)
Figure 9: Plaintext Figure 9: Plaintext
5.4. Additional Authenticated Data 5.4. Additional Authenticated Data
The external_aad SHALL be a CBOR array wrapped in a bstr object as The external_aad SHALL be a CBOR array wrapped in a bstr object as
defined below: defined below, following the notation of [RFC8610] as summarized in
Appendix E:
external_aad = bstr .cbor aad_array external_aad = bstr .cbor aad_array
aad_array = [ aad_array = [
oscore_version : uint, oscore_version : uint,
algorithms : [ alg_aead : int / tstr ], algorithms : [ alg_aead : int / tstr ],
request_kid : bstr, request_kid : bstr,
request_piv : bstr, request_piv : bstr,
options : bstr, options : bstr,
] ]
skipping to change at page 29, line 7 skipping to change at page 31, line 7
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
in the original CoAP message encoded as described in Section 3.1 in the original CoAP message encoded as described in Section 3.1
of [RFC7252], where the delta is the difference to the previously of [RFC7252], where the delta is the difference from the
included instance of class I option. previously included instance of class I option.
The oscore_version and algorithms parameters are established out-of- The oscore_version and algorithms parameters are established out-of-
band and are thus never transported in OSCORE, but the external_aad band; thus, they are not transported in OSCORE, but the external_aad
allows to verify that they are the same in both endpoints. allows to verify that they are the same in both endpoints.
NOTE: The format of the external_aad is for simplicity the same for NOTE: The format of the external_aad is, for simplicity, the same for
requests and responses, although some parameters, e.g. request_kid, requests and responses, although some parameters, e.g., request_kid,
need not be integrity protected in all requests. need not be integrity protected in all requests.
The Additional Authenticated Data (AAD) is composed from the The AAD is composed from the external_aad as described in Section 5.3
external_aad as described in Section 5.3 of [RFC8152]: of [RFC8152] (the notation follows [RFC8610] as summarized in
Appendix E):
AAD = Enc_structure = [ "Encrypt0", h'', external_aad ] AAD = Enc_structure = [ "Encrypt0", h'', external_aad ]
The following is an example of AAD constructed using AEAD Algorithm = The following is an example of AAD constructed using AEAD Algorithm =
AES-CCM-16-64-128 (10), request_kid = 0x00, request_piv = 0x25 and no AES-CCM-16-64-128 (10), request_kid = 0x00, request_piv = 0x25 and no
Class I options: Class I options:
o oscore_version: 0x01 (1 byte) o oscore_version: 0x01 (1 byte)
o algorithms: 0x810a (2 bytes) o algorithms: 0x810a (2 bytes)
skipping to change at page 29, line 51 skipping to change at page 31, line 52
o AAD: 0x8368456e63727970743040498501810a4100412540 (21 bytes) o AAD: 0x8368456e63727970743040498501810a4100412540 (21 bytes)
Note that the AAD consists of a fixed string of 11 bytes concatenated Note that the AAD consists of a fixed string of 11 bytes concatenated
with the external_aad. with the external_aad.
6. OSCORE Header Compression 6. OSCORE Header Compression
The Concise Binary Object Representation (CBOR) [RFC7049] combines The Concise Binary Object Representation (CBOR) [RFC7049] combines
very small message sizes with extensibility. The CBOR Object Signing very small message sizes with extensibility. The CBOR Object Signing
and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding
of signed and encrypted data. COSE is however constructed to support of signed and encrypted data. However, COSE is constructed to
a large number of different stateless use cases, and is not fully support a large number of different stateless use cases and is not
optimized for use as a stateful security protocol, leading to a fully optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion. In this section, we define larger than necessary message expansion. In this section, we define
a stateless header compression mechanism, simply removing redundant a stateless header compression mechanism, simply removing redundant
information from the COSE objects, which significantly reduces the information from the COSE objects, which significantly reduces the
per-packet overhead. The result of applying this mechanism to a COSE per-packet overhead. The result of applying this mechanism to a COSE
object is called the "compressed COSE object". object is called the "compressed COSE object".
The COSE_Encrypt0 object used in OSCORE is transported in the OSCORE The COSE_Encrypt0 object used in OSCORE is transported in the OSCORE
option and in the Payload. The Payload contains the Ciphertext of option and in the Payload. The Payload contains the ciphertext of
the COSE object. The headers of the COSE object are compactly the COSE object. The headers of the COSE object are compactly
encoded as described in the next section. encoded as described in the next section.
6.1. Encoding of the OSCORE Option Value 6.1. Encoding of the OSCORE Option Value
The value of the OSCORE option SHALL contain the OSCORE flag bits, The value of the OSCORE option SHALL contain the OSCORE flag bits,
the Partial IV parameter, the 'kid context' parameter (length and the 'Partial IV' parameter, the 'kid context' parameter (length and
value), and the 'kid' parameter as follows: value), and the 'kid' parameter as follows:
0 1 2 3 4 5 6 7 <------------- n bytes --------------> 0 1 2 3 4 5 6 7 <------------- n bytes -------------->
+-+-+-+-+-+-+-+-+-------------------------------------- +-+-+-+-+-+-+-+-+--------------------------------------
|0 0 0|h|k| n | Partial IV (if any) ... |0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+-------------------------------------- +-+-+-+-+-+-+-+-+--------------------------------------
<- 1 byte -> <----- s bytes ------> <- 1 byte -> <----- s bytes ------>
+------------+----------------------+------------------+ +------------+----------------------+------------------+
| s (if any) | kid context (if any) | kid (if any) ... | | s (if any) | kid context (if any) | kid (if any) ... |
+------------+----------------------+------------------+ +------------+----------------------+------------------+
Figure 10: The OSCORE Option Value Figure 10: The OSCORE Option Value
o The first byte, containing the OSCORE flag bits, encodes the o The first byte, containing the OSCORE flag bits, encodes the
following set of bits and the length of the Partial IV parameter: following set of bits and the length of the 'Partial IV'
parameter:
* The three least significant bits encode the Partial IV length * The three least significant bits encode the Partial IV length
n. If n = 0 then the Partial IV is not present in the n. If n = 0, then the Partial IV is not present in the
compressed COSE object. The values n = 6 and n = 7 are compressed COSE object. The values n = 6 and n = 7 are
reserved. reserved.
* The fourth least significant bit is the 'kid' flag, k: it is * The fourth least significant bit is the 'kid' flag, k. It is
set to 1 if the kid is present in the compressed COSE object. set to 1 if 'kid' is present in the compressed COSE object.
* The fifth least significant bit is the 'kid context' flag, h: * The fifth least significant bit is the 'kid context' flag, h.
it is set to 1 if the compressed COSE object contains a 'kid It is set to 1 if the compressed COSE object contains a 'kid
context (see Section 5.1). context' (see Section 5.1).
* The sixth to eighth least significant bits are reserved for * The sixth-to-eighth least significant bits are reserved for
future use. These bits SHALL be set to zero when not in use. future use. These bits SHALL be set to zero when not in use.
According to this specification, if any of these bits are set According to this specification, if any of these bits are set
to 1 the message is considered to be malformed and to 1, the message is considered to be malformed and
decompression fails as specified in item 2 of Section 8.2. decompression fails as specified in item 2 of Section 8.2.
The flag bits are registered in the OSCORE Flag Bits registry The flag bits are registered in the "OSCORE Flag Bits" registry
specified in Section 13.7. specified in Section 13.7.
o The following n bytes encode the value of the Partial IV, if the o The following n bytes encode the value of the Partial IV, if the
Partial IV is present (n > 0). Partial IV is present (n > 0).
o The following 1 byte encode the length of the 'kid context' o The following 1 byte encodes the length s of the 'kid context'
(Section 5.1) s, if the 'kid context' flag is set (h = 1). (Section 5.1), if the 'kid context' flag is set (h = 1).
o The following s bytes encode the 'kid context', if the 'kid o The following s bytes encode the 'kid context', if the 'kid
context' flag is set (h = 1). context' flag is set (h = 1).
o The remaining bytes encode the value of the 'kid', if the 'kid' is o The remaining bytes encode the value of the 'kid', if the 'kid' is
present (k = 1). present (k = 1).
Note that the 'kid' MUST be the last field of the OSCORE option Note that the 'kid' MUST be the last field of the OSCORE option
value, even in case reserved bits are used and additional fields are value, even in the case in which reserved bits are used and
added to it. additional fields are added to it.
The length of the OSCORE option thus depends on the presence and The length of the OSCORE option thus depends on the presence and
length of Partial IV, 'kid context', 'kid', as specified in this length of Partial IV, 'kid context', 'kid', as specified in this
section, and on the presence and length of the other parameters, as section, and on the presence and length of additional parameters, as
defined in the separate documents. defined in the future documents registering those parameters.
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 This section covers a list of OSCORE Header Compression examples for
requests and responses. The examples assume the COSE_Encrypt0 object requests and responses. The examples assume the COSE_Encrypt0 object
is set (which means the CoAP message and cryptographic material is is set (which means the CoAP message and cryptographic material is
known). Note that the full CoAP unprotected message, as well as the known). Note that the full CoAP unprotected message, as well as the
full security context, is not reported in the examples, but only the full security context, is not reported in the examples, but only the
input necessary to the compression mechanism, i.e. the COSE_Encrypt0 input necessary to the compression mechanism, i.e., the COSE_Encrypt0
object. The output is the compressed COSE object as defined in object. The output is the compressed COSE object as defined in
Section 6, divided into two parts, since the object is transported in Section 6, divided into two parts, since the object is transported in
two CoAP fields: OSCORE option and payload. two CoAP fields: the OSCORE option and payload.
1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 1. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
0x25, and Partial IV = 0x05 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):
skipping to change at page 32, line 46 skipping to change at page 34, line 50
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes) Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid = 3. Request with ciphertext = 0xaea0155667924dff8a24e4cb35b9, kid =
empty string, Partial IV = 0x05, and kid context = 0x44616c656b empty string, Partial IV = 0x05, and kid context = 0x44616c656b
Before compression (30 bytes): Before compression (30 bytes):
[ [
h'', h'',
{ 4:h'', 6:h'05', 8:h'44616c656b' }, { 4:h'', 6:h'05', 10:h'44616c656b' },
h'aea0155667924dff8a24e4cb35b9', h'aea0155667924dff8a24e4cb35b9',
] ]
After compression (22 bytes): After compression (22 bytes):
Flag byte: 0b00011001 = 0x19 (1 byte) Flag byte: 0b00011001 = 0x19 (1 byte)
Option Value: 0x19050544616c656b (8 bytes) Option Value: 0x19050544616c656b (8 bytes)
Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes) Payload: 0xae a0155667924dff8a24e4cb35b9 (14 bytes)
skipping to change at page 34, line 10 skipping to change at page 36, line 10
Option Value: 0x0107 (2 bytes) Option Value: 0x0107 (2 bytes)
Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes) Payload: 0xaea0155667924dff8a24e4cb35b9 (14 bytes)
7. Message Binding, Sequence Numbers, Freshness, and Replay Protection 7. Message Binding, Sequence Numbers, Freshness, and Replay Protection
7.1. Message Binding 7.1. Message Binding
In order to prevent response delay and mismatch attacks In order to prevent response delay and mismatch attacks
[I-D.mattsson-core-coap-actuators] from on-path attackers and [CoAP-Actuators] from on-path attackers and compromised
compromised intermediaries, OSCORE binds responses to the requests by intermediaries, OSCORE binds responses to the requests by including
including the 'kid' and Partial IV of the request in the AAD of the the 'kid' and Partial IV of the request in the AAD of the response.
response. The server therefore needs to store the 'kid' and Partial Therefore, the server needs to store the 'kid' and Partial IV of the
IV of the request until all responses have been sent. request until all responses have been sent.
7.2. Sequence Numbers 7.2. Sequence Numbers
An AEAD nonce MUST NOT be used more than once per AEAD key. The An AEAD nonce MUST NOT be used more than once per AEAD key. The
uniqueness of (key, nonce) pairs is shown in Appendix D.4, and in uniqueness of (key, nonce) pairs is shown in Appendix D.4, and in
particular depends on a correct usage of Partial IVs (which encode particular depends on a correct usage of Partial IVs (which encode
the Sender Sequence Numbers, see Section 5). If messages are the Sender Sequence Numbers, see Section 5). If messages are
processed concurrently, the operation of reading and increasing the processed concurrently, the operation of reading and increasing the
Sender Sequence Number MUST be atomic. Sender Sequence Number MUST be atomic.
7.2.1. Maximum Sequence Number 7.2.1. Maximum Sequence Number
The maximum Sender Sequence Number is algorithm dependent (see The maximum Sender Sequence Number is algorithm dependent (see
Section 12), and SHALL be less than 2^40. If the Sender Sequence Section 12) 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. If necessary, the endpoint messages with the given Sender Context. If necessary, the endpoint
SHOULD acquire a new security context before this happens. The SHOULD acquire a new security context before this happens. The
latter is out of scope of this document. 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),
OSCORE needs to be augmented with mechanisms providing freshness, for OSCORE needs to be augmented with mechanisms providing freshness (for
example as specified in [I-D.ietf-core-echo-request-tag]. example, as specified in [CoAP-ECHO-REQ-TAG]).
Assuming an honest server (see Appendix D), the message binding Assuming an honest server (see Appendix D), the message binding
guarantees that a response is not older than its request. For guarantees that a response is not older than its request. For
responses that are not notifications (i.e. when there is a single responses that are not notifications (i.e., when there is a single
response to a request), this gives absolute freshness. For response to a request), this gives absolute freshness. For
notifications, the absolute freshness gets weaker with time, and it notifications, the absolute freshness gets weaker with time, and it
is RECOMMENDED that the client regularly re-register the observation. is RECOMMENDED that the client regularly re-register the observation.
Note that the message binding does not guarantee that misbehaving Note that the message binding does not guarantee that a misbehaving
server created the response before receiving the request, i.e. it server created the response before receiving the request, i.e., it
does not verify server aliveness. does not verify server aliveness.
For requests and notifications, OSCORE also provides relative For requests and notifications, OSCORE also provides relative
freshness in the sense that the received Partial IV allows a freshness in the sense that the received Partial IV allows a
recipient to determine the relative order of requests or responses. recipient to determine the relative order of requests or 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 the
Partial IV = Sender Sequence Number received in the COSE object has Sender Sequence Number received in the 'Partial IV' parameter of the
not been received before. If this verification fails, the server COSE object (see Section 6.1) has not been received before. If this
SHALL stop processing the message, and MAY optionally respond with a verification fails, the server SHALL stop processing the message, and
4.01 (Unauthorized) error message. Also, the server MAY set an Outer it MAY optionally respond with a 4.01 (Unauthorized) error message.
Max-Age option with value zero, to inform any intermediary that the Also, the server MAY set an Outer Max-Age option with value zero to
response is not to be cached. The diagnostic payload MAY contain the inform any intermediary that the response is not to be cached. The
"Replay detected" string. The size and type of the Replay Window diagnostic payload MAY contain the string "Replay detected". The
depends on the use case and the protocol with which the OSCORE size and type of the Replay Window depends on the use case and the
message is transported. In case of reliable and ordered transport protocol with which the OSCORE message is transported. In case of
from endpoint to endpoint, e.g. TCP, the server MAY just store the reliable and ordered transport from endpoint to endpoint, e.g., TCP,
last received Partial IV and require that newly received Partial IVs the server MAY just store the last received Partial IV and require
equals the last received Partial IV + 1. However, in case of mixed that newly received Partial IVs equal the last received Partial IV +
reliable and unreliable transports and where messages may be lost, 1. However, in the case of mixed reliable and unreliable transports
such a replay mechanism may be too restrictive and the default replay and where messages may be lost, such a replay mechanism may be too
window be more suitable (see Section 3.2.2). restrictive and the default replay window may be more suitable (see
Section 3.2.2).
Responses (with or without Partial IV) are protected against replay Responses (with or without Partial IV) are protected against replay
as they are bound to the request and the fact that only a single as they are bound to the request and the fact that only a single
response is accepted. Note that the Partial IV is not used for response is accepted. In this case the Partial IV is not used for
replay protection in this case. replay protection of responses.
The operation of validating the Partial IV and updating the replay The operation of validating the Partial IV and updating the replay
protection MUST be atomic. protection MUST be atomic.
7.4.1. Replay Protection of Notifications 7.4.1. Replay Protection of Notifications
The following applies additionally when Observe is supported. The following applies additionally when the Observe option is
supported.
The Notification Number is initialized to the Partial IV of the first The Notification Number (see Section 4.1.3.5.2) is initialized to the
successfully verified notification in response to the registration Partial IV of the first successfully verified notification in
request. A client MUST only accept at most one Observe notifications response to the registration request. A client MUST only accept at
without Partial IV, and treat it as the oldest notification received. most one Observe notification without Partial IV, and treat it as the
A client receiving a notification containing a Partial IV SHALL oldest notification received. A client receiving a notification
compare the Partial IV with the Notification Number associated to containing a Partial IV SHALL compare the Partial IV with the
that Observe registration. The client MUST stop processing Notification Number associated to that Observe registration. The
notifications with a Partial IV which has been previously received. client MUST stop processing notifications with a Partial IV that has
Applications MAY decide that a client only processes notifications been previously received. Applications MAY decide that a client only
which have greater Partial IV than the Notification Number. processes notifications that have a greater Partial IV than the
Notification Number.
If the verification of the response succeeds, and the received If the verification of the response succeeds, and the received
Partial IV was greater than the Notification Number then the client Partial IV was greater than the Notification Number, then the client
SHALL overwrite the corresponding Notification Number with the SHALL overwrite the corresponding Notification Number with the
received Partial IV. received Partial IV.
7.5. Losing Part of the Context State 7.5. Losing Part of the Context State
To prevent reuse of an AEAD nonce with the same AEAD key, or from To prevent reuse of an AEAD nonce with the same AEAD key or the
accepting replayed messages, an endpoint needs to handle the acceptance of replayed messages, an endpoint needs to handle the
situation of losing rapidly changing parts of the context, such as situation of losing rapidly changing parts of the context, such as
the Sender Sequence Number, and Replay Window. These are typically the Sender Sequence Number and Replay Window. These are typically
stored in RAM and therefore lost in the case of e.g. an unplanned stored in RAM and therefore lost in the case of, e.g., an unplanned
reboot. There are different alternatives to recover, for example: reboot. There are different alternatives to recover, for example:
1. The endpoints can reuse an existing Security Context after 1. The endpoints can reuse an existing Security Context after
updating the mutable parts of the security context (Sender updating the mutable parts of the security context (Sender
Sequence Number, and Replay Window). This requires that the Sequence Number and Replay Window). This requires that the
mutable parts of the security context are available throughout mutable parts of the security context are available throughout
the lifetime of the device, or that the device can establish safe the lifetime of the device or that the device can establish a
security context after loss of mutable security context data. fresh security context after loss of mutable security context
Examples is given based on careful use of non-volatile memory, data. Examples are given based on careful use of nonvolatile
see Appendix B.1.1, and additionally the use of the Echo option, memory, see Appendix B.1.1 and the use of the Echo option, see
see Appendix B.1.2. If an endpoint makes use of a partial Appendix B.1.2. If an endpoint makes use of a partial security
security context stored in non-volatile memory, it MUST NOT reuse context stored in nonvolatile memory, it MUST NOT reuse a
a previous Sender Sequence Number and MUST NOT accept previously previous Sender Sequence Number and MUST NOT accept previously
received messages. received messages.
2. The endpoints can reuse an existing shared Master Secret and 2. The endpoints can reuse an existing shared Master Secret and
derive new Sender and Recipient Contexts, see Appendix B.2 for an derive new Sender and Recipient Contexts, see Appendix B.2 for an
example. This typically requires a good source of randomness. example. This typically requires a good source of randomness.
3. The endpoints can use a trusted-third party assisted key 3. The endpoints can use a trusted third-party-assisted key
establishment protocol such as [I-D.ietf-ace-oscore-profile]. establishment protocol such as [OSCORE-PROFILE]. This requires
This requires the execution of three-party protocol and may the execution of a three-party protocol and may require a good
require a good source of randomness. source of randomness.
4. The endpoints can run a key exchange protocol providing forward 4. The endpoints can run a key exchange protocol providing forward
secrecy resulting in a fresh Master Secret, from which an secrecy resulting in a fresh Master Secret, from which an
entirely new Security Context is derived. This requires a good entirely new Security Context is derived. This requires a good
source of randomness, and additionally, the transmission and source of randomness, and additionally, the transmission and
processing of the protocol may have a non-negligible cost, e.g. processing of the protocol may have a non-negligible cost, e.g.,
in terms of power consumption. in terms of power consumption.
The endpoints need to be configured with information about which The endpoints need to be configured with information about which
method is used. The choice of method may depend on capabilities of method is used. The choice of method may depend on capabilities of
the devices deployed and the solution architecture. Using a key the devices deployed and the solution architecture. Using a key
exchange protocol is necessary for deployments that require forward exchange protocol is necessary for deployments that require forward
secrecy. secrecy.
8. Processing 8. Processing
skipping to change at page 37, line 21 skipping to change at page 39, line 27
destination pair are used to match a response with a request, both destination pair are used to match a response with a request, both
endpoints MUST keep the association (Token, {Security Context, endpoints MUST keep the association (Token, {Security Context,
Partial IV of the request}), in order to be able to find the Security Partial IV of the request}), in order to be able to find the Security
Context and compute the AAD to protect or verify the response. The Context and compute the AAD to protect or verify the response. The
association MAY be forgotten after it has been used to successfully association MAY be forgotten after it has been used to successfully
protect or verify the response, with the exception of Observe protect or verify the response, with the exception of Observe
processing, where the association MUST be kept as long as the processing, where the association MUST be kept as long as the
Observation is active. Observation is active.
The processing of the Sender Sequence Number follows the procedure The processing of the Sender Sequence Number follows the procedure
described in Section 3 of [I-D.mcgrew-iv-gen]. described in Section 3 of [IV-GEN].
8.1. Protecting the Request 8.1. Protecting the Request
Given a CoAP request, the client SHALL perform the following steps to Given a CoAP request, the client SHALL perform the following steps to
create an OSCORE request: create an OSCORE request:
1. Retrieve the Sender Context associated with the target resource. 1. Retrieve the Sender Context associated with the target resource.
2. Compose the Additional Authenticated Data and the plaintext, as 2. Compose the AAD and the plaintext, as described in Sections 5.3
described in Sections 5.3 and 5.4. and 5.4.
3. Encode the Partial IV (Sender Sequence Number in network byte 3. Encode the Partial IV (Sender Sequence Number in network byte
order) and increment the Sender Sequence Number by one. Compute order) and increment the Sender Sequence Number by one. Compute
the AEAD nonce from the Sender ID, Common IV, and Partial IV as the AEAD nonce from the Sender ID, Common IV, and Partial IV as
described in Section 5.2. described in Section 5.2.
4. Encrypt the COSE object using the Sender Key. Compress the COSE 4. Encrypt the COSE object using the Sender Key. Compress the COSE
Object as specified in Section 6. object as specified in Section 6.
5. Format the OSCORE message according to Section 4. The OSCORE 5. Format the OSCORE message according to Section 4. The OSCORE
option is added (see Section 4.1.2). option is added (see Section 4.1.2).
8.2. Verifying the Request 8.2. Verifying the Request
A server receiving a request containing the OSCORE option SHALL A server receiving a request containing the OSCORE option SHALL
perform the following steps: perform the following steps:
1. Discard Code and all class E options (marked in Figure 5 with 'x' 1. Discard Code and all Class E options (marked in Figure 5 with 'x'
in column E) present in the received message. For example, an in column E) present in the received message. For example, an
If-Match Outer option is discarded, but an Uri-Host Outer option If-Match Outer option is discarded, but an Uri-Host Outer option
is not discarded. is not discarded.
2. Decompress the COSE Object (Section 6) and retrieve the Recipient 2. Decompress the COSE object (Section 6) and retrieve the Recipient
Context associated with the Recipient ID in the 'kid' parameter, Context associated with the Recipient ID in the 'kid' parameter,
additionally using the 'kid context', if present. If either the additionally using the 'kid context', if present. Note that the
Recipient Context MAY be retrieved by deriving a new security
context, e.g. as described in Appendix B.2. If either the
decompression or the COSE message fails to decode, or the server decompression or the COSE message fails to decode, or the server
fails to retrieve a Recipient Context with Recipient ID fails to retrieve a Recipient Context with Recipient ID
corresponding to the 'kid' parameter received, then the server corresponding to the 'kid' parameter received, then the server
SHALL stop processing the request. SHALL stop processing the request.
* If either the decompression or the COSE message fails to * If either the decompression or the COSE message fails to
decode, the server MAY respond with a 4.02 (Bad Option) error decode, the server MAY respond with a 4.02 (Bad Option) 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 MAY contain the string value zero. The diagnostic payload MAY contain the string
"Failed to decode COSE". "Failed to decode COSE".
* If the server fails to retrieve a Recipient Context with * If the server fails to retrieve a Recipient Context with
Recipient ID corresponding to the 'kid' parameter received, Recipient ID corresponding to the 'kid' parameter received,
the server MAY respond with a 4.01 (Unauthorized) error the server MAY respond with a 4.01 (Unauthorized) 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 MAY contain the string value zero. The diagnostic payload MAY contain the string
"Security context not found". "Security context not found".
3. Verify that the 'Partial IV' has not been received before using 3. Verify that the Partial IV has not been received before using the
the Replay Window, as described in Section 7.4. Replay Window, as described in Section 7.4.
4. Compose the Additional Authenticated Data, as described in 4. Compose the AAD, as described in Section 5.4.
Section 5.4.
5. Compute the AEAD nonce from the Recipient ID, Common IV, and the 5. Compute the AEAD nonce from the Recipient ID, Common IV, and the
'Partial IV' parameter, received in the COSE Object. Partial IV, received in the COSE object.
6. Decrypt the COSE object using the Recipient Key, as per [RFC8152] 6. Decrypt the COSE object using the Recipient Key, as per
Section 5.3. (The decrypt operation includes the verification of Section 5.3 of [RFC8152]. (The decrypt operation includes the
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 MAY contain the value zero. The diagnostic payload MAY contain the string
"Decryption failed" string. "Decryption failed".
* If decryption succeeds, update the Replay Window, as described * If decryption succeeds, update the Replay Window, as described
in Section 7. in Section 7.
7. Add decrypted Code, options, and payload to the decrypted 7. Add decrypted Code, options, and payload to the decrypted
request. The OSCORE option is removed. request. The OSCORE option is removed.
8. The decrypted CoAP request is processed according to [RFC7252]. 8. The decrypted CoAP request is processed according to [RFC7252].
8.2.1. Supporting Block-wise 8.2.1. Supporting Block-wise
skipping to change at page 39, line 21 skipping to change at page 41, line 39
Block options according to [RFC7959], until all blocks of the request Block options according to [RFC7959], until all blocks of the request
have been received (see Section 4.1.3.4). have been received (see Section 4.1.3.4).
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 (step 8 in Section 8.2) are protected, as well as processing (step 8 in Section 8.2) are protected, as well as
successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6 successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6
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.
1. Retrieve the Sender Context in the Security Context associated 1. Retrieve the Sender Context in the Security Context associated
with the Token. with the Token.
2. Compose the Additional Authenticated Data and the plaintext, as 2. Compose the AAD and the plaintext, as described in Sections 5.3
described in Sections 5.3 and 5.4. and 5.4.
3. Compute the AEAD nonce as described in Section 5.2: 3. Compute the AEAD nonce as described in Section 5.2:
* Either use the AEAD nonce from the request, or * Either use the AEAD nonce from the request, or
* Encode the Partial IV (Sender Sequence Number in network byte * Encode the Partial IV (Sender Sequence Number in network byte
order) and increment the Sender Sequence Number by one. order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV. Partial IV.
4. Encrypt the COSE object using the Sender Key. Compress the COSE 4. Encrypt the COSE object using the Sender Key. Compress the COSE
Object as specified in Section 6. If the AEAD nonce was object as specified in Section 6. If the AEAD nonce was
constructed from a new Partial IV, this Partial IV MUST be constructed from a new Partial IV, this Partial IV MUST be
included in the message. If the AEAD nonce from the request was included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message. used, the Partial IV MUST NOT be included in the message.
5. Format the OSCORE message according to Section 4. The OSCORE 5. Format the OSCORE message according to Section 4. The OSCORE
option is added (see Section 4.1.2). option is added (see Section 4.1.2).
8.3.1. Supporting Observe 8.3.1. Supporting Observe
If Observe is supported, insert the following step between step 2 and If Observe is supported, insert the following step between steps 2
3 of Section 8.3: and 3 of Section 8.3:
A. If the response is an observe notification: A. If the response is an Observe notification:
o If the response is the first notification: o If the response is the first notification:
* compute the AEAD nonce as described in Section 5.2: * compute the AEAD nonce as described in Section 5.2:
+ Either use the AEAD nonce from the request, or + Either use the AEAD nonce from the request, or
+ Encode the Partial IV (Sender Sequence Number in network + Encode the Partial IV (Sender Sequence Number in network
byte order) and increment the Sender Sequence Number by one. byte order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV. Partial IV.
Then go to 4. Then, go to 4.
o If the response is not the first notification: o If the response is not the first notification:
* encode the Partial IV (Sender Sequence Number in network byte * encode the Partial IV (Sender Sequence Number in network byte
order) and increment the Sender Sequence Number by one. order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV, then go to 4. Partial IV, then go to 4.
8.4. Verifying the Response 8.4. Verifying the Response
A client receiving a response containing the OSCORE option SHALL A client receiving a response containing the OSCORE option SHALL
perform the following steps: perform the following steps:
1. Discard Code and all class E options (marked in Figure 5 with 'x' 1. Discard Code and all Class E options (marked in Figure 5 with 'x'
in column E) present in the received message. For example, ETag in column E) present in the received message. For example, ETag
Outer option is discarded, as well as Max-Age Outer option. Outer option is discarded, as well as Max-Age Outer option.
2. Retrieve the Recipient Context in the Security Context associated 2. Retrieve the Recipient Context in the Security Context associated
with the Token. Decompress the COSE Object (Section 6). If with the Token. Decompress the COSE object (Section 6). If
either the decompression or the COSE message fails to decode, either the decompression or the COSE message fails to decode,
then go to 8. then go to 8.
3. Compose the Additional Authenticated Data, as described in 3. Compose the AAD, as described in Section 5.4.
Section 5.4.
4. Compute the AEAD nonce 4. Compute the AEAD nonce
* If the Partial IV is not present in the response, the AEAD * If the Partial IV is not present in the response, the AEAD
nonce from the request is used. nonce from the request is used.
* If the Partial IV is present in the response, compute the AEAD * If the Partial IV is present in the response, compute the AEAD
nonce from the Recipient ID, Common IV, and the 'Partial IV' nonce from the Recipient ID, Common IV, and the Partial IV,
parameter, received in the COSE Object. received in the COSE object.
5. Decrypt the COSE object using the Recipient Key, as per [RFC8152] 5. Decrypt the COSE object using the Recipient Key, as per
Section 5.3. (The decrypt operation includes the verification of Section 5.3 of [RFC8152]. (The decrypt operation includes the
the integrity.) If decryption fails, then go to 8. verification of the integrity.) If decryption fails, then go to
8.
6. Add decrypted Code, options and payload to the decrypted request. 6. Add decrypted Code, options and payload to the decrypted request.
The OSCORE option is removed. The OSCORE option is removed.
7. The decrypted CoAP response is processed according to [RFC7252]. 7. The decrypted CoAP response is processed according to [RFC7252].
8. In case any of the previous erroneous conditions apply: the 8. In case any of the previous erroneous conditions apply: the
client SHALL stop processing the response. client SHALL stop processing the response.
8.4.1. Supporting Block-wise 8.4.1. Supporting Block-wise
If Block-wise is supported, insert the following step before any If Block-wise is supported, insert the following step before any
other: other:
A. If Block-wise is present in the request, then process the Outer A. If Block-wise is present in the response, then process the Outer
Block options according to [RFC7959], until all blocks of the request Block options according to [RFC7959], until all blocks of the
have been received (see Section 4.1.3.4). response have been received (see Section 4.1.3.4).
8.4.2. Supporting Observe 8.4.2. Supporting Observe
If Observe is supported: If Observe is supported:
Insert the following step between step 5 and step 6: Insert the following step between step 5 and step 6:
A. If the request was an Observe registration, then: A. If the request was an Observe registration, then:
o If the Partial IV is not present in the response, and Inner o If the Partial IV is not present in the response, and the Inner
Observe is present, and the AEAD nonce from the request was Observe option is present, and the AEAD nonce from the request was
already used once, then go to 8. already used once, then go to 8.
o If the Partial IV is present in the response and Inner Observe is o If the Partial IV is present in the response and the Inner Observe
present, then follow the processing described in Section 4.1.3.5.2 option is present, then follow the processing described in
and Section 7.4.1, then: Section 4.1.3.5.2 and Section 7.4.1, then:
* initialize the Notification Number (if first successfully * initialize the Notification Number (if first successfully
verified notification), or verified notification), or
* overwrite the Notification Number (if the received Partial IV * overwrite the Notification Number (if the received Partial IV
was greater than the Notification Number). was greater than the Notification Number).
Replace step 8 of Section 8.4 with: Replace step 8 of Section 8.4 with:
B. In case any of the previous erroneous conditions apply: the B. In case any of the previous erroneous conditions apply: the
client SHALL stop processing the response. An error condition client SHALL stop processing the response. An error condition
occurring while processing a response to an observation request does occurring while processing a response to an observation request does
not cancel the observation. A client MUST NOT react to failure by not cancel the observation. A client MUST NOT react to failure by
re-registering the observation immediately. 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 "osc" attribute in a
web link [RFC8288] to a resource, e.g. using a link-format document web link [RFC8288] to a resource, e.g., using a link-format document
[RFC6690] if the resource is accessible over CoAP. [RFC6690] if the resource is accessible over CoAP.
The "osc" attribute is a hint indicating that the destination of that The "osc" attribute is a hint indicating that the destination of that
link is only accessible using OSCORE, and unprotected access to it is link is only accessible using OSCORE, and unprotected access to it is
not supported. Note that this is simply a hint, it does not include not supported. Note that this is simply a hint, it does not include
any security context material or any other information required to any security context material or any other information required to
run OSCORE. run OSCORE.
A value MUST NOT be given for the "osc" attribute; any present value A value MUST NOT be given for the "osc" attribute; any present value
MUST be ignored by parsers. The "osc" attribute MUST NOT appear more MUST be ignored by parsers. The "osc" attribute MUST NOT appear more
than once in a given link-value; occurrences after the first MUST be than once in a given link-value; occurrences after the first MUST be
ignored by parsers. ignored by parsers.
The example in Figure 11 shows a use of the "osc" attribute: the The example in Figure 11 shows a use of the "osc" attribute: the
client does resource discovery on a server, and gets back a list of client does resource discovery on a server and gets back a list of
resources, one of which includes the "osc" attribute indicating that resources, one of which includes the "osc" attribute indicating that
the resource is protected with OSCORE. The link-format notation (see the resource is protected with OSCORE. The link-format notation (see
Section 5 of [RFC6690]) is used. Section 5 of [RFC6690]) is used.
REQ: GET /.well-known/core REQ: GET /.well-known/core
RES: 2.05 Content RES: 2.05 Content
</sensors/temp>;osc, </sensors/temp>;osc,
</sensors/light>;if="sensor" </sensors/light>;if="sensor"
Figure 11: The web link Figure 11: The Web Link
10. CoAP-to-CoAP Forwarding Proxy 10. CoAP-to-CoAP Forwarding Proxy
CoAP is designed for proxy operations (see Section 5.7 of [RFC7252]). CoAP is designed for proxy operations (see Section 5.7 of [RFC7252]).
OSCORE is designed to work with OSCORE-unaware CoAP proxies. OSCORE is designed to work with OSCORE-unaware CoAP proxies.
Security requirements for forwarding are listed in Section 2.2.1 of Security requirements for forwarding are listed in Section 2.2.1 of
[I-D.hartke-core-e2e-security-reqs]. Proxy processing of the (Outer) [CoAP-E2E-Sec]. Proxy processing of the (Outer) Proxy-Uri option
Proxy-Uri option works as defined in [RFC7252]. Proxy processing of works as defined in [RFC7252]. Proxy processing of the (Outer) Block
the (Outer) Block options works as defined in [RFC7959]. options works as defined in [RFC7959].
However, not all CoAP proxy operations are useful: However, not all CoAP proxy operations are useful:
o Since a CoAP response is only applicable to the original CoAP o Since a CoAP response is only applicable to the original CoAP
request, caching is in general not useful. In support of existing request, caching is in general not useful. In support of existing
proxies, OSCORE uses the outer Max-Age option, see proxies, OSCORE uses the Outer Max-Age option, see
Section 4.1.3.1. Section 4.1.3.1.
o Proxy processing of the (Outer) Observe option as defined in o Proxy processing of the (Outer) Observe option as defined in
[RFC7641] is specified in Section 4.1.3.5. [RFC7641] is specified in Section 4.1.3.5.
Optionally, a CoAP proxy MAY detect OSCORE and act accordingly. An Optionally, a CoAP proxy MAY detect OSCORE and act accordingly. An
OSCORE-aware CoAP proxy: OSCORE-aware CoAP proxy:
o SHALL bypass caching for the request if the OSCORE option is o SHALL bypass caching for the request if the OSCORE option is
present present.
o SHOULD avoid caching responses to requests with an OSCORE option o SHOULD avoid caching responses to requests with an OSCORE option.
In the case of Observe (see Section 4.1.3.5) the OSCORE-aware CoAP In the case of Observe (see Section 4.1.3.5), the OSCORE-aware CoAP
proxy: proxy:
o SHALL NOT initiate an Observe registration o SHALL NOT initiate an Observe registration.
o MAY verify the order of notifications using Partial IV rather than o MAY verify the order of notifications using Partial IV rather than
the Observe option the Observe option.
11. HTTP Operations 11. HTTP Operations
The CoAP request/response model may be mapped to HTTP and vice versa The CoAP request/response model may be mapped to HTTP and vice versa
as described in Section 10 of [RFC7252]. The HTTP-CoAP mapping is as described in Section 10 of [RFC7252]. The HTTP-CoAP mapping is
further detailed in [RFC8075]. This section defines the components further detailed in [RFC8075]. This section defines the components
needed to map and transport OSCORE messages over HTTP hops. By needed to map and transport OSCORE messages over HTTP hops. By
mapping between HTTP and CoAP and by using cross-protocol proxies mapping between HTTP and CoAP and by using cross-protocol proxies,
OSCORE may be used end-to-end between e.g. an HTTP client and a CoAP OSCORE may be used end-to-end between, e.g., an HTTP client and a
server. Examples are provided at the end of the section. CoAP server. Examples are provided in Sections 11.5 and 11.6.
11.1. The HTTP OSCORE Header Field 11.1. The HTTP OSCORE Header Field
The HTTP OSCORE Header Field (see Section 13.4) is used for carrying The HTTP OSCORE header field (see Section 13.4) is used for carrying
the content of the CoAP OSCORE option when transporting OSCORE the content of the CoAP OSCORE option when transporting OSCORE
messages over HTTP hops. messages over HTTP hops.
The HTTP OSCORE header field is only used in POST requests and 200 The HTTP OSCORE header field is only used in POST requests and
(OK) responses. When used, the HTTP header field Content-Type is set responses with HTTP Status Code 200 (OK). When used, the HTTP header
to 'application/oscore' (see Section 13.5) indicating that the HTTP field Content-Type is set to 'application/oscore' (see Section 13.5)
body of this message contains the OSCORE payload (see Section 6.2). indicating that the HTTP body of this message contains the OSCORE
No additional semantics is provided by other message fields. payload (see Section 6.2). No additional semantics are provided by
other message fields.
Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], Using the Augmented Backus-Naur Form (ABNF) notation of [RFC5234],
including the following core ABNF syntax rules defined by that including the following core ABNF syntax rules defined by that
specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP specification: ALPHA (letters) and DIGIT (decimal digits), the HTTP
OSCORE header field value is as follows. OSCORE header field value is as follows.
base64url-char = ALPHA / DIGIT / "-" / "_" base64url-char = ALPHA / DIGIT / "-" / "_"
OSCORE = 2*base64url-char OSCORE = 2*base64url-char
The HTTP OSCORE header field is not appropriate to list in the The HTTP OSCORE header field is not appropriate to list in the
Connection header field (see Section 6.1 of [RFC7230]) since it is Connection header field (see Section 6.1 of [RFC7230]) since it is
not hop-by-hop. OSCORE messages are generally not useful when served not hop-by-hop. OSCORE messages are generally not useful when served
from cache (i.e., they will generally be marked Cache-Control: no- from cache (i.e., they will generally be marked Cache-Control: no-
cache) and so interaction with Vary is not relevant (Section 7.1.4 of cache) and so interaction with Vary is not relevant (Section 7.1.4 of
[RFC7231]). Since the HTTP OSCORE header field is critical for [RFC7231]). Since the HTTP OSCORE header field is critical for
message processing, moving it from headers to trailers renders the message processing, moving it from headers to trailers renders the
message unusable in case trailers are ignored (see Section 4.1 of message unusable in case trailers are ignored (see Section 4.1 of
[RFC7230]). [RFC7230]).
Intermediaries are in general not allowed to insert, delete, or In general, intermediaries are not allowed to insert, delete, or
modify the OSCORE header. Changes to the HTTP OSCORE header field modify the OSCORE header. In general, changes to the HTTP OSCORE
will in general violate the integrity of the OSCORE message resulting header field will violate the integrity of the OSCORE message
in an error. For the same reason the HTTP OSCORE header field is in resulting in an error. For the same reason the HTTP OSCORE header
general not preserved across redirects. field is generally not preserved across redirects.
Since redirects are not defined in the mappings between HTTP and CoAP Since redirects are not defined in the mappings between HTTP and CoAP
[RFC8075][RFC7252], a number of conditions need to be fulfilled for ([RFC8075] [RFC7252]), a number of conditions need to be fulfilled
redirects to work. For CoAP client to HTTP server, such conditions for redirects to work. For CoAP-client-to-HTTP-server redirects,
include: such conditions include:
o the CoAP-to-HTTP proxy follows the redirect, instead of the CoAP o the CoAP-to-HTTP proxy follows the redirect, instead of the CoAP
client as in the HTTP case client as in the HTTP case.
o the CoAP-to-HTTP proxy copies the HTTP OSCORE header field and o the CoAP-to-HTTP proxy copies the HTTP OSCORE header field and
body to the new request body to the new request.
o the target of the redirect has the necessary OSCORE security o the target of the redirect has the necessary OSCORE security
context required to decrypt and verify the message context required to decrypt and verify the message.
Since OSCORE requires HTTP body to be preserved across redirects, the Since OSCORE requires the HTTP body to be preserved across redirects,
HTTP server is RECOMMENDED to reply with 307 or 308 instead of 301 or the HTTP server is RECOMMENDED to reply with 307 (Temporary Redirect)
302. or 308 (Permanent Redirect) instead of 301 (Moved Permanently) or 302
(Found).
For the case of HTTP client to CoAP server, although redirect is not For the case of HTTP-client-to-CoAP-server redirects, although
defined for CoAP servers [RFC7252], an HTTP client receiving a redirect is not defined for CoAP servers [RFC7252], an HTTP client
redirect should generate a new OSCORE request for the server it was receiving a redirect should generate a new OSCORE request for the
redirected to. server it was redirected to.
11.2. CoAP-to-HTTP Mapping 11.2. CoAP-to-HTTP Mapping
Section 10.1 of [RFC7252] describes the fundamentals of the CoAP-to- Section 10.1 of [RFC7252] describes the fundamentals of the CoAP-to-
HTTP cross-protocol mapping process. The additional rules for OSCORE HTTP cross-protocol mapping process. The additional rules for OSCORE
messages are: messages are as follows:
o The HTTP OSCORE header field value is set to o The HTTP OSCORE header field value is set to:
* AA if the CoAP OSCORE option is empty, otherwise * AA if the CoAP OSCORE option is empty; otherwise,
* the value of the CoAP OSCORE option (Section 6.1) in base64url * the value of the CoAP OSCORE option (Section 6.1) in base64url
(Section 5 of [RFC4648]) encoding without padding. (Section 5 of [RFC4648]) encoding without padding.
Implementation notes for this encoding are given in Appendix C Implementation notes for this encoding are given in Appendix C
of [RFC7515]. of [RFC7515].
o The HTTP Content-Type is set to 'application/oscore' (see o The HTTP Content-Type is set to 'application/oscore' (see
Section 13.5), independent of CoAP Content-Format. Section 13.5), independent of CoAP Content-Format.
11.3. HTTP-to-CoAP Mapping 11.3. HTTP-to-CoAP Mapping
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. The additional rules for HTTP messages with the HTTP-to-CoAP proxy. The additional rules for HTTP messages with the
OSCORE header field are: OSCORE header field are as follows.
o The CoAP OSCORE option is set as follows: o The CoAP OSCORE option is set as follows:
* empty if the value of the HTTP OSCORE header field is a single * empty if the value of the HTTP OSCORE header field is a single
zero byte (0x00) represented by AA, otherwise zero byte (0x00) represented by AA; otherwise,
* the value of the HTTP OSCORE header field decoded from * the value of the HTTP OSCORE header field decoded from
base64url (Section 5 of [RFC4648]) without padding. base64url (Section 5 of [RFC4648]) without padding.
Implementation notes for this encoding are given in Appendix C Implementation notes for this encoding are given in Appendix C
of [RFC7515]. of [RFC7515].
o The CoAP Content-Format option is omitted, the content format for o The CoAP Content-Format option is omitted, the content format for
OSCORE (Section 13.6) MUST NOT be used. OSCORE (Section 13.6) MUST NOT be used.
11.4. HTTP Endpoints 11.4. HTTP Endpoints
skipping to change at page 46, line 7 skipping to change at page 48, line 43
with the rules in Section 11.1. with the rules in Section 11.1.
The receiving HTTP endpoint maps the HTTP message to a CoAP message The receiving HTTP endpoint maps the HTTP message to a CoAP message
using [RFC8075] and Section 11.3. The resulting OSCORE message is using [RFC8075] and Section 11.3. The resulting OSCORE message is
processed as defined in this document. If successful, the plaintext processed as defined in this document. If successful, the plaintext
CoAP message is translated to HTTP for normal processing in the CoAP message is translated to HTTP for normal processing in the
endpoint. endpoint.
11.5. Example: HTTP Client and CoAP Server 11.5. Example: HTTP Client and CoAP Server
This section is giving an example of how a request and a response This section gives an example of what a request and a response
between an HTTP client and a CoAP server could look like. The between an HTTP client and a CoAP server could look like. The
example is not a test vector but intended as an illustration of how example is not a test vector but intended as an illustration of how
the message fields are translated in the different steps. the message fields are translated in the different steps.
Mapping and notation here is based on "Simple Form" (Section 5.4.1 of Mapping and notation here is based on "Simple Form" (Section 5.4.1 of
[RFC8075]). [RFC8075]).
[HTTP request -- Before client object security processing] [HTTP request -- Before client object security processing]
GET http://proxy.url/hc/?target_uri=coap://server.url/orders GET http://proxy.url/hc/?target_uri=coap://server.url/orders
skipping to change at page 47, line 18 skipping to change at page 50, line 5
Content-Type: application/oscore Content-Type: application/oscore
OSCORE: AA OSCORE: AA
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- After client object security processing] [HTTP response -- After client object security processing]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/plain Content-Type: text/plain
Body: Exterminate! Exterminate! Body: Exterminate! Exterminate!
Note that the HTTP Status Code 200 in the next-to-last message is the Note that the HTTP Status Code 200 (OK) in the next-to-last message
mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200 is the mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status
in the last message is the mapping of the CoAP Code 2.05 (Content), Code 200 (OK) in the last message is the mapping of the CoAP Code
which was encrypted within the compressed COSE object carried in the 2.05 (Content), which was encrypted within the compressed COSE object
Body of the HTTP response. carried in the Body of the HTTP response.
11.6. Example: CoAP Client and HTTP Server 11.6. Example: CoAP Client and HTTP Server
This section is giving an example of how a request and a response This section gives an example of what a request and a response
between a CoAP client and an HTTP server could look like. The between a CoAP client and an HTTP server could look like. The
example is not a test vector but intended as an illustration of how example is not a test vector but intended as an illustration of how
the message fields are translated in the different steps the message fields are translated in the different steps.
[CoAP request -- Before client object security processing] [CoAP request -- Before client object security processing]
GET coap://proxy.url/ GET coap://proxy.url/
Proxy-Uri=http://server.url/orders Proxy-Uri=http://server.url/orders
[CoAP request -- CoAP Client to Proxy] [CoAP request -- CoAP Client to Proxy]
POST coap://proxy.url/ POST coap://proxy.url/
Proxy-Uri=http://server.url/ Proxy-Uri=http://server.url/
skipping to change at page 48, line 31 skipping to change at page 51, line 18
OSCORE: [empty] OSCORE: [empty]
Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- After client object security processing] [CoAP response -- After client object security processing]
2.05 Content 2.05 Content
Content-Format: 0 Content-Format: 0
Payload: Exterminate! Exterminate! Payload: Exterminate! Exterminate!
Note that the HTTP Code 2.04 (Changed) in the next-to-last message is Note that the HTTP Code 2.04 (Changed) in the next-to-last message is
the mapping of HTTP Status Code 200, whereas the CoAP Code 2.05 the mapping of HTTP Status Code 200 (OK), whereas the CoAP Code 2.05
(Content) in the last message is the value that was encrypted within (Content) in the last message is the value that was encrypted within
the compressed COSE object carried in the Body of the HTTP response. the compressed COSE object carried in the Body of the HTTP response.
12. Security Considerations 12. Security Considerations
An overview of the security properties is given in Appendix D. An overview of the security properties is given in Appendix D.
12.1. End-to-end Protection 12.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,
skipping to change at page 49, line 9 skipping to change at page 51, line 44
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
point and intermediary node. In particular when OSCORE is used with endpoint and intermediary node. In particular, when OSCORE is used
HTTP, the additional TLS protection of HTTP hops is RECOMMENDED, e.g. with HTTP, the additional TLS protection of HTTP hops is RECOMMENDED,
between an HTTP endpoint and a proxy translating between HTTP and e.g., between an HTTP endpoint and a proxy translating between HTTP
CoAP. and CoAP.
Applications need to consider that certain message fields and Applications need to consider that certain message fields and
messages types are not protected end-to-end and may be spoofed or messages types are not protected end-to-end and may be spoofed or
manipulated. The consequences of unprotected message fields are manipulated. The consequences of unprotected message fields are
analyzed in Appendix D.5. analyzed in Appendix D.5.
12.2. Security Context Establishment 12.2. Security Context Establishment
The use of COSE_Encrypt0 and AEAD to protect messages as specified in The use of COSE_Encrypt0 and AEAD to protect messages as specified in
this document requires an established security context. The method this document requires an established security context. The method
to establish the security context described in Section 3.2 is based to establish the security context described in Section 3.2 is based
on a common Master Secret and unique Sender IDs. The necessary input on a common Master Secret and unique Sender IDs. The necessary input
parameters may be pre-established or obtained using a key parameters may be preestablished or obtained using a key
establishment protocol augmented with establishment of Sender/ establishment protocol augmented with establishment of Sender/
Recipient ID, such as a key exchange protocol or the OSCORE profile Recipient ID, such as a key exchange protocol or the OSCORE profile
of the ACE framework [I-D.ietf-ace-oscore-profile]. Such a procedure of the Authentication and Authorization for Constrained Environments
must ensure that the requirements of the security context parameters (ACE) framework [OSCORE-PROFILE]. Such a procedure must ensure that
for the intended use are complied with (see Section 3.3) and also in the requirements of the security context parameters for the intended
error situations. While recipient IDs are allowed to coincide use are complied with (see Section 3.3) even in error situations.
between different security contexts (see Section 3.3), this may cause While recipient IDs are allowed to coincide between different
a server to process multiple verifications before finding the right security contexts (see Section 3.3), this may cause a server to
security context or rejecting a message. Considerations for process multiple verifications before finding the right security
deploying OSCORE with a fixed Master Secret are given in Appendix B. context or rejecting a message. Considerations for deploying OSCORE
with a fixed Master Secret are given in Appendix B.
12.3. Master Secret 12.3. Master Secret
OSCORE uses HKDF [RFC5869] and the established input parameters to OSCORE uses HKDF [RFC5869] and the established input parameters to
derive the security context. The required properties of the security derive the security context. The required properties of the security
context parameters are discussed in Section 3.3, in this section we context parameters are discussed in Section 3.3; in this section, we
focus on the Master Secret. HKDF denotes in this specification the focus on the Master Secret. In this specification, HKDF denotes the
composition of the expand and extract functions as defined in composition of the expand and extract functions as defined in
[RFC5869] and the Master Secret is used as Input Key Material (IKM). [RFC5869] and the Master Secret is used as Input Keying Material
(IKM).
Informally, HKDF takes as source an IKM containing some good amount Informally, HKDF takes as source an IKM containing some good amount
of randomness but not necessarily distributed uniformly (or for which of randomness but not necessarily distributed uniformly (or for which
an attacker has some partial knowledge) and derive from it one or an attacker has some partial knowledge) and derive from it one or
more cryptographically strong secret keys [RFC5869]. more cryptographically strong secret keys [RFC5869].
Therefore, the main requirement for the OSCORE Master Secret, in Therefore, the main requirement for the OSCORE Master Secret, in
addition to being secret, is that it is has a good amount of addition to being secret, is that it have a good amount of
randomness. The selected key establishment schemes must ensure that randomness. The selected key establishment schemes must ensure that
the necessary properties for the Master Secret are fulfilled. For the necessary properties for the Master Secret are fulfilled. For
pre-shared key deployments and key transport solutions such as pre-shared key deployments and key transport solutions such as
[I-D.ietf-ace-oscore-profile], the Master Secret can be generated [OSCORE-PROFILE], the Master Secret can be generated offline using a
offline using a good random number generator. Randomness good random number generator. Randomness requirements for security
requirements for security are described in [RFC4086]. are described in [RFC4086].
12.4. Replay Protection 12.4. Replay Protection
Replay attacks need to be considered in different parts of the Replay attacks need to be considered in different parts of the
implementation. Most AEAD algorithms require a unique nonce for each implementation. Most AEAD algorithms require a unique nonce for each
message, for which the sender sequence numbers in the COSE message message, for which the Sender Sequence Numbers in the COSE message
field 'Partial IV' is used. If the recipient accepts any sequence field 'Partial IV' is used. If the recipient accepts any sequence
number larger than the one previously received, then the problem of number larger than the one previously received, then the problem of
sequence number synchronization is avoided. With reliable transport, sequence number synchronization is avoided. With reliable transport,
it may be defined that only messages with sequence number which are it may be defined that only messages with sequence numbers that are
equal to previous sequence number + 1 are accepted. An adversary may equal to the previous sequence number + 1 are accepted. An adversary
try to induce a device reboot for the purpose of replaying a message may try to induce a device reboot for the purpose of replaying a
(see Section 7.5). message (see Section 7.5).
Note that sharing a security context between servers may open up for Note that sharing a security context between servers may open up for
replay attacks, for example if the replay windows are not replay attacks, for example, if the Replay Windows are not
synchronized. synchronized.
12.5. Client Aliveness 12.5. Client Aliveness
A verified OSCORE request enables the server to verify the identity A verified OSCORE request enables the server to verify the identity
of the entity who generated the message. However, it does not verify of the entity who generated the message. However, it does not verify
that the client is currently involved in the communication, since the that the client is currently involved in the communication, since the
message may be a delayed delivery of a previously generated request message may be a delayed delivery of a previously generated request,
which now reaches the server. To verify the aliveness of the client which now reaches the server. To verify the aliveness of the client
the server may use the Echo option in the response to a request from the server may use the Echo option in the response to a request from
the client (see [I-D.ietf-core-echo-request-tag]). the client (see [CoAP-ECHO-REQ-TAG]).
12.6. Cryptographic Considerations 12.6. 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 is 2^40 - 1, or any algorithm. The maximum Sender Sequence Number is 2^40 - 1, or any
algorithm specific lower limit, after which a new security context algorithm-specific lower limit, after which a new security context
must be generated. The mechanism to build the AEAD nonce must be generated. The mechanism to build the AEAD nonce
(Section 5.2) assumes that the nonce is at least 56 bits, and the (Section 5.2) assumes that the nonce is at least 56 bits, and the
Partial IV is at most 40 bits. The mandatory-to-implement AEAD Partial IV is at most 40 bits. The mandatory-to-implement AEAD
algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*. algorithm AES-CCM-16-64-128 is selected for compatibility with CCM*.
AEAD algorithms that require unpredictable nonces are not supported. AEAD algorithms that require unpredictable nonces are not supported.
In order to prevent cryptanalysis when the same plaintext is In order to prevent cryptanalysis when the same plaintext is
repeatedly encrypted by many different users with distinct AEAD keys, repeatedly encrypted by many different users with distinct AEAD keys,
the AEAD nonce is formed by mixing the sequence number with a secret the AEAD nonce is formed by mixing the sequence number with a secret
per-context initialization vector (Common IV) derived along with the per-context initialization vector (Common IV) derived along with the
skipping to change at page 51, line 25 skipping to change at page 54, line 15
The ID Context, Sender ID, and Partial IV are always at least The ID Context, Sender ID, and Partial IV are always at least
implicitly integrity protected, as manipulation leads to the wrong implicitly integrity protected, as manipulation leads to the wrong
nonce or key being used and therefore results in decryption failure. nonce or key being used and therefore results in decryption failure.
12.7. Message Segmentation 12.7. 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 that can, by policy, be
in size since the Inner Block options allow for secure fragmentation restricted in size since the Inner Block options allow for secure
of very large messages. A maximum message size (above which the fragmentation of very large messages. A maximum message size (above
sending endpoint fragments the message and the receiving endpoint which the sending endpoint fragments the message and the receiving
discards the message, if complying to the policy) may be obtained as endpoint discards the message, if complying to the policy) may be
part of normal resource discovery. obtained as part of normal resource discovery.
12.8. Privacy Considerations 12.8. Privacy Considerations
Privacy threats executed through intermediary nodes are considerably Privacy threats executed through intermediary nodes are considerably
reduced by means of OSCORE. End-to-end integrity protection and reduced by means of OSCORE. End-to-end integrity protection and
encryption of the message payload and all options that are not used encryption of the message payload and all options that are not used
for proxy operations, provide mitigation against attacks on sensor for proxy operations provide mitigation against attacks on sensor and
and actuator communication, which may have a direct impact on the actuator communication, which may have a direct impact on the
personal sphere. personal sphere.
The unprotected options (Figure 5) may reveal privacy sensitive The unprotected options (Figure 5) may reveal privacy-sensitive
information, see Appendix D.5. CoAP headers sent in plaintext allow, information, see Appendix D.5. CoAP headers sent in plaintext allow,
for example, matching of CON and ACK (CoAP Message Identifier), for example, matching of CON and ACK (CoAP Message Identifier),
matching of request and responses (Token) and traffic analysis. matching of request and responses (Token) and traffic analysis.
OSCORE does not provide protection for HTTP header fields which are OSCORE does not provide protection for HTTP header fields that are
not both CoAP-mappable and class E. The HTTP message fields which not both CoAP-mappable and Class E. The HTTP message fields that are
are visible to on-path entity are only used for the purpose of visible to on-path entities are only used for the purpose of
transporting the OSCORE message, whereas the application layer transporting the OSCORE message, whereas the application-layer
message is encoded in CoAP and encrypted. message is encoded in CoAP and encrypted.
COSE message fields, i.e. the OSCORE option, may reveal information COSE message fields, i.e., the OSCORE option, may reveal information
about the communicating endpoints. E.g. 'kid' and 'kid context', about the communicating endpoints. For example, 'kid' and 'kid
which are intended to help the server find the right context, may context', which are intended to help the server find the right
reveal information about the client. Tracking 'kid' and 'kid context, may reveal information about the client. Tracking 'kid' and
context' to one server may be used for correlating requests from one 'kid context' to one server may be used for correlating requests from
client. one client.
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
signaling messages reveal information about the reliable transport signaling 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. traffic analysis.
13. IANA Considerations 13. IANA Considerations
Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this specification.
Note to IANA: Please note all occurrences of "TBD1" in this
specification should be assigned the same number.
13.1. COSE Header Parameters Registry 13.1. COSE Header Parameters Registry
The 'kid context' parameter is added to the "COSE Header Parameters The 'kid context' parameter has been added to the "COSE Header
Registry": Parameters" registry:
o Name: kid context o Name: kid context
o Label: TBD2 o Label: 10
o Value Type: bstr o Value Type: bstr
o Value Registry: o Value Registry:
o Description: Identifies the context for 'kid' o Description: Identifies the context for the key identifier
o Reference: Section 5.1 of this document o Reference: Section 5.1 of this document
Note to IANA: Label assignment in (Integer value between 1 and 255)
is requested. (RFC Editor: Delete this note after IANA assignment)
13.2. CoAP Option Numbers Registry 13.2. CoAP Option Numbers Registry
The OSCORE option is added to the CoAP Option Numbers registry: The OSCORE option has been added to the "CoAP Option Numbers"
registry:
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| TBD1 | OSCORE | [[this document]] | | 9 | OSCORE | [RFC8613] |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
Note to IANA: Label assignment in (Integer value between 0 and 12) is Furthermore, the following existing entries in the "CoAP Option
requested. We also request Expert review if possible, to make sure a Numbers" registry have been updated with a reference to the document
correct number for the option is selected (RFC Editor: Delete this
note after IANA assignment)
Furthermore, the following existing entries in the CoAP Option
Numbers registry are updated with a reference to the document
specifying OSCORE processing of that option: specifying OSCORE processing of that option:
+--------+-----------------+---------------------------------------+ +--------+-----------------+-------------------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-----------------+---------------------------------------+ +--------+-----------------+-------------------------------+
| 1 | If-Match | [RFC7252] [[this document]] | | 1 | If-Match | [RFC7252] [RFC8613] |
| 3 | Uri-Host | [RFC7252] [[this document]] | | 3 | Uri-Host | [RFC7252] [RFC8613] |
| 4 | ETag | [RFC7252] [[this document]] | | 4 | ETag | [RFC7252] [RFC8613] |
| 5 | If-None-Match | [RFC7252] [[this document]] | | 5 | If-None-Match | [RFC7252] [RFC8613] |
| 6 | Observe | [RFC7641] [[this document]] | | 6 | Observe | [RFC7641] [RFC8613] |
| 7 | Uri-Port | [RFC7252] [[this document]] | | 7 | Uri-Port | [RFC7252] [RFC8613] |
| 8 | Location-Path | [RFC7252] [[this document]] | | 8 | Location-Path | [RFC7252] [RFC8613] |
| 11 | Uri-Path | [RFC7252] [[this document]] | | 11 | Uri-Path | [RFC7252] [RFC8613] |
| 12 | Content-Format | [RFC7252] [[this document]] | | 12 | Content-Format | [RFC7252] [RFC8613] |
| 14 | Max-Age | [RFC7252] [[this document]] | | 14 | Max-Age | [RFC7252] [RFC8613] |
| 15 | Uri-Query | [RFC7252] [[this document]] | | 15 | Uri-Query | [RFC7252] [RFC8613] |
| 17 | Accept | [RFC7252] [[this document]] | | 17 | Accept | [RFC7252] [RFC8613] |
| 20 | Location-Query | [RFC7252] [[this document]] | | 20 | Location-Query | [RFC7252] [RFC8613] |
| 23 | Block2 | [RFC7959] [RFC8323] [[this document]] | | 23 | Block2 | [RFC7959] [RFC8323] [RFC8613] |
| 27 | Block1 | [RFC7959] [RFC8323] [[this document]] | | 27 | Block1 | [RFC7959] [RFC8323] [RFC8613] |
| 28 | Size2 | [RFC7959] [[this document]] | | 28 | Size2 | [RFC7959] [RFC8613] |
| 35 | Proxy-Uri | [RFC7252] [[this document]] | | 35 | Proxy-Uri | [RFC7252] [RFC8613] |
| 39 | Proxy-Scheme | [RFC7252] [[this document]] | | 39 | Proxy-Scheme | [RFC7252] [RFC8613] |
| 60 | Size1 | [RFC7252] [[this document]] | | 60 | Size1 | [RFC7252] [RFC8613] |
| 258 | No-Response | [RFC7967] [[this document]] | | 258 | No-Response | [RFC7967] [RFC8613] |
+--------+-----------------+---------------------------------------+ +--------+-----------------+-------------------------------+
Future additions to the CoAP Option Numbers registry need to provide Future additions to the "CoAP Option Numbers" registry need to
a reference to the document where the OSCORE processing of that CoAP provide a reference to the document where the OSCORE processing of
Option is defined. that CoAP Option is defined.
13.3. CoAP Signaling Option Numbers Registry 13.3. CoAP Signaling Option Numbers Registry
The OSCORE option is added to the CoAP Signaling Option Numbers The OSCORE option has been added to the "CoAP Signaling Option
registry: Numbers" registry:
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| 7.xx (all) | TBD1 | OSCORE | [[this document]] | | 7.xx (all) | 9 | OSCORE | [RFC8613] |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
Note to IANA: The value in the "Number" field is the same value
that's being assigned to the new Option Number. Please make sure
TBD1 is not the same as any value in Numbers for any existing entry
in the CoAP Signaling Option Numbers registry (at the time of writing
this, that means make sure TBD1 is not 2 or 4)(RFC Editor: Delete
this note after IANA assignment)
13.4. Header Field Registrations 13.4. Header Field Registrations
The HTTP OSCORE header field is added to the Message Headers The HTTP OSCORE header field has been added to the "Message Headers"
registry: registry:
+-------------------+----------+----------+---------------------+ +-------------------+----------+----------+---------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+---------------------+ +-------------------+----------+----------+---------------------+
| OSCORE | http | standard | [[this document]], | | OSCORE | http | standard | [RFC8613], |
| | | | Section 11.1 | | | | | Section 11.1 |
+-------------------+----------+----------+---------------------+ +-------------------+----------+----------+---------------------+
13.5. Media Type Registrations 13.5. Media Type Registration
This section registers the 'application/oscore' media type in the This section registers the 'application/oscore' media type in the
"Media Types" registry. These media types are used to indicate that "Media Types" registry. This media type is used to indicate that the
the content is an OSCORE message. The OSCORE body cannot be content is an OSCORE message. The OSCORE body cannot be understood
understood without the OSCORE header field value and the security without the OSCORE header field value and the security context.
context.
Type name: application Type name: application
Subtype name: oscore Subtype name: oscore
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: binary Encoding considerations: binary
Security considerations: See the Security Considerations section Security considerations: See the Security Considerations section
of [[This document]]. of [RFC8613].
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: [[This document]] Published specification: [RFC8613]
Applications that use this media type: IoT applications sending Applications that use this media type: IoT applications sending
security content over HTTP(S) transports. security content over HTTP(S) transports.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
* Deprecated alias names for this type: N/A * Deprecated alias names for this type: N/A
* Magic number(s): N/A * Magic number(s): N/A
* File extension(s): N/A * File extension(s): N/A
* Macintosh file type code(s): N/A * Macintosh file type code(s): N/A
Person & email address to contact for further information: Person & email address to contact for further information:
iesg@ietf.org IESG <iesg@ietf.org>
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
13.6. CoAP Content-Formats Registry 13.6. CoAP Content-Formats Registry
Note to IANA: ID assignment in the 10000-64999 range is requested.
(RFC Editor: Delete this note after IANA assignment)
This section registers the media type 'application/oscore' media type This section registers the media type 'application/oscore' media type
in the "CoAP Content-Formats" registry. This Content-Format for the in the "CoAP Content-Formats" registry. This Content-Format for the
OSCORE payload is defined for potential future use cases and SHALL OSCORE payload is defined for potential future use cases and SHALL
NOT be used in the OSCORE message. The OSCORE payload cannot be NOT be used in the OSCORE message. The OSCORE payload cannot be
understood without the OSCORE option value and the security context. understood without the OSCORE option value and the security context.
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
| Media Type | Encoding | ID | Reference | | Media Type | Encoding | ID | Reference |
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
| application/oscore | | TBD3 | [[this document]] | | application/oscore | | 10001 | [RFC8613] |
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
13.7. OSCORE Flag Bits Registry 13.7. OSCORE Flag Bits Registry
This document defines a sub-registry for the OSCORE flag bits within This document defines a subregistry for the OSCORE flag bits within
the "CoRE Parameters" registry. The name of the sub-registry is the "CoRE Parameters" registry. The name of the subregistry is
"OSCORE Flag Bits". The registry should be created with the Expert "OSCORE Flag Bits". The registry has been created with the Expert
Review policy. Guidelines for the experts are provided in Review policy [RFC8126]. Guidelines for the experts are provided in
Section 13.8. Section 13.8.
The columns of the registry are: The columns of the registry are as follows:
o bit position: This indicates the position of the bit in the set of o Bit Position: This indicates the position of the bit in the set of
OSCORE flag bits, starting at 0 for the most significant bit. The OSCORE flag bits, starting at 0 for the most significant bit. The
bit position must be an integer or a range of integers, in the bit position must be an integer or a range of integers, in the
range 0 to 63. range 0 to 63.
o name: The name is present to make it easier to refer to and o Name: The name is present to make it easier to refer to and
discuss the registration entry. The value is not used in the discuss the registration entry. The value is not used in the
protocol. Names are to be unique in the table. protocol. Names are to be unique in the table.
o description: This contains a brief description of the use of the o Description: This contains a brief description of the use of the
bit. bit.
o specification: This contains a pointer to the specification o Reference: This contains a pointer to the specification defining
defining the entry. the entry.
The initial contents of the registry can be found in the table below. The initial contents of the registry are in the table below. The
The specification column for all rows in that table should be this reference column for all rows is this document. The entries with Bit
document. The entries with Bit Position of 0 and 1 are to be marked Position of 0 and 1 are marked as 'Reserved'. The entry with Bit
as 'Reserved'. The entry with Bit Position of 1 is going to be Position of 1 will be specified in a future document and will be used
specified in a future document, and will be used to expand the space to expand the space for the OSCORE flag bits in Section 6.1, so that
for the OSCORE flag bits in Section 6.1, so that entries 8-63 of the entries 8-63 of the registry are defined.
registry are defined.
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+-----------------------------+-----------+
| Bit Position | Name | Description | Specification | | Bit Position | Name | Description | Reference |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+-----------------------------+-----------+
| 0 | Reserved | | | | 0 | Reserved | | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+-----------------------------+-----------+
| 1 | Reserved | | | | 1 | Reserved | | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+-----------------------------+-----------+
| 2 | Unassigned | | | | 2 | Unassigned | | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+-----------------------------+-----------+
| 3 | Kid Context | Set to 1 if 'kid | [[this document]] | | 3 | Kid Context | Set to 1 if kid context | [RFC8613] |
| | Flag | context' is present | | | | Flag | is present in the | |
| | | in the compressed | | | | | compressed COSE object | |
| | | COSE object | | +--------------+-------------+-----------------------------+-----------+
+--------------+-------------+---------------------+-------------------+ | 4 | Kid Flag | Set to 1 if kid is present | [RFC8613] |
| 4 | Kid Flag | Set to 1 if kid is | [[this document]] | | | | in the compressed COSE | |
| | | present in the com- | | | | | object | |
| | | pressed COSE object | | +--------------+-------------+-----------------------------+-----------+
+--------------+-------------+---------------------+-------------------+ | 5-7 | Partial IV | Encodes the Partial IV | [RFC8613] |
| 5-7 | Partial IV | Encodes the Partial | [[this document]] | | | Length | length; can have value | |
| | Length | IV length; can have | | | | | 0 to 5 | |
| | | value 0 to 5 | | +--------------+-------------+-----------------------------+-----------+
+--------------+-------------+---------------------+-------------------+ | 8-63 | Unassigned | | |
| 8-63 | Unassigned | | | +--------------+-------------+-----------------------------+-----------+
+--------------+-------------+---------------------+-------------------+
13.8. Expert Review Instructions 13.8. Expert Review Instructions
The expert reviewers for the registry defined in this document are The expert reviewers for the registry defined in this document are
expected to ensure that the usage solves a valid use case that could expected to ensure that the usage solves a valid use case that could
not be solved better in a different way, that it is not going to not be solved better in a different way, that it is not going to
duplicate one that is already registered, and that the registered duplicate one that is already registered, and that the registered
point is likely to be used in deployments. They are furthermore point is likely to be used in deployments. They are furthermore
expected to check the clarity of purpose and use of the requested expected to check the clarity of purpose and use of the requested
code points. Experts should take into account the expected usage of code points. Experts should take into account the expected usage of
entries when approving point assignment, and the length of the entries when approving point assignment, and the length of the
encoded value should be weighed against the number of code points encoded value should be weighed against the number of code points
left that encode to that size and the size of device it will be used left that encode to that size and the size of device it will be used
on. Experts should block registration for entries 8-63 until these on. Experts should block registration for entries 8-63 until these
points are defined (i.e. until the mechanism for the OSCORE flag bits points are defined (i.e., until the mechanism for the OSCORE flag
expansion via bit 1 is specified). bits expansion via bit 1 is specified).
14. References 14. References
14.1. Normative References 14.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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 59, line 48 skipping to change at page 62, line 5
[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>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
14.2. Informative References [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
[I-D.bormann-6lo-coap-802-15-ie] Express Concise Binary Object Representation (CBOR) and
Bormann, C., "Constrained Application Protocol (CoAP) over JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
IEEE 802.15.4 Information Element for IETF", draft- June 2019, <https://www.rfc-editor.org/info/rfc8610>.
bormann-6lo-coap-802-15-ie-00 (work in progress), April
2016.
[I-D.hartke-core-e2e-security-reqs] 14.2. Informative References
Selander, G., Palombini, F., and K. Hartke, "Requirements
for CoAP End-To-End Security", draft-hartke-core-e2e-
security-reqs-03 (work in progress), July 2017.
[I-D.ietf-ace-oauth-authz] [ACE-OAuth]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace-
(work in progress), March 2019. oauth-authz-24, March 2019.
[I-D.ietf-ace-oscore-profile] [CoAP-802.15.4]
Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, Bormann, C., "Constrained Application Protocol (CoAP) over
"OSCORE profile of the Authentication and Authorization IEEE 802.15.4 Information Element for IETF", Work in
for Constrained Environments Framework", draft-ietf-ace- Progress, draft-bormann-6lo-coap-802-15-ie-00, April 2016.
oscore-profile-07 (work in progress), February 2019.
[I-D.ietf-cbor-cddl] [CoAP-Actuators]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
definition language (CDDL): a notational convention to and C. Amsuess, "Controlling Actuators with CoAP", Work in
express CBOR and JSON data structures", draft-ietf-cbor- Progress, draft-mattsson-core-coap-actuators-06, September
cddl-07 (work in progress), February 2019. 2018.
[I-D.ietf-core-echo-request-tag] [CoAP-E2E-Sec]
Amsuess, C., Mattsson, J., and G. Selander, "Echo and Selander, G., Palombini, F., and K. Hartke, "Requirements
Request-Tag", draft-ietf-core-echo-request-tag-03 (work in for CoAP End-To-End Security", Work in Progress, draft-
progress), October 2018. hartke-core-e2e-security-reqs-03, July 2017.
[I-D.ietf-core-oscore-groupcomm] [CoAP-ECHO-REQ-TAG]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", Work in Progress,
draft-ietf-core-echo-request-tag-04, March 2019.
[Group-OSCORE]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Group OSCORE - Secure Group Communication for CoAP", "Group OSCORE - Secure Group Communication for CoAP", Work
draft-ietf-core-oscore-groupcomm-03 (work in progress), in Progress, draft-ietf-core-oscore-groupcomm-04, March
October 2018. 2019.
[I-D.mattsson-core-coap-actuators] [IV-GEN] McGrew, D., "Generation of Deterministic Initialization
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Vectors (IVs) and Nonces", Work in Progress, draft-mcgrew-
and C. Amsuess, "Controlling Actuators with CoAP", draft- iv-gen-03, October 2013.
mattsson-core-coap-actuators-06 (work in progress),
September 2018.
[I-D.mcgrew-iv-gen] [MF00] McGrew, D. and S. Fluhrer, "Attacks on Additive Encryption
McGrew, D., "Generation of Deterministic Initialization of Redundant Plaintext and Implications on Internet
Vectors (IVs) and Nonces", draft-mcgrew-iv-gen-03 (work in Security", Proceedings of the Seventh Annual Workshop on
progress), October 2013. Selected Areas in Cryptography (SAC 2000) Springer-
Verlag., pp. 14-28, 2000.
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of [OSCORE-PROFILE]
Redundant Plaintext and Implications on Internet Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
Security", the Proceedings of the Seventh Annual Workshop "OSCORE profile of the Authentication and Authorization
on Selected Areas in Cryptography (SAC 2000), Springer- for Constrained Environments Framework", Work in
Verlag. , 2000. Progress, draft-ietf-ace-oscore-profile-07, February 2019.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D.
Dissertation, University of California, Irvine, 2010.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 62, line 5 skipping to change at page 64, line 10
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Scenario Examples Appendix A. Scenario Examples
This section gives examples of OSCORE, targeting scenarios in This section gives examples of OSCORE, targeting scenarios in
Section 2.2.1.1 of [I-D.hartke-core-e2e-security-reqs]. The message Section 2.2.1.1 of [CoAP-E2E-Sec]. The message exchanges are made,
exchanges are made, based on the assumption that there is a security based on the assumption that there is a security context established
context established between client and server. For simplicity, these between client and server. For simplicity, these examples only
examples only indicate the content of the messages without going into indicate the content of the messages without going into detail of the
detail of the (compressed) COSE message format. (compressed) COSE message format.
A.1. Secure Access to Sensor A.1. Secure Access to Sensor
This example illustrates a client requesting the alarm status from a This example illustrates a client requesting the alarm status from a
server. server.
Client Proxy Server Client Proxy Server
| | | | | |
+------>| | Code: 0.02 (POST) +------>| | Code: 0.02 (POST)
| POST | | Token: 0x8c | POST | | Token: 0x8c
skipping to change at page 62, line 44 skipping to change at page 65, line 44
| | 2.04 | Token: 0x7b | | 2.04 | Token: 0x7b
| | | OSCORE: - | | | OSCORE: -
| | | Payload: {Code:2.05, "0"} | | | Payload: {Code:2.05, "0"}
| | | | | |
|<------+ | Code: 2.04 (Changed) |<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c | 2.04 | | Token: 0x8c
| | | OSCORE: - | | | OSCORE: -
| | | Payload: {Code:2.05, "0"} | | | Payload: {Code:2.05, "0"}
| | | | | |
Figure 12: Secure Access to Sensor. Square brackets [ ... ] indicate Square brackets [ ... ] indicate content of compressed COSE object.
content of compressed COSE object. Curly brackets { ... } indicate Curly brackets { ... } indicate encrypted data.
encrypted data.
The request/response Codes are encrypted by OSCORE and only dummy Figure 12: Secure Access to Sensor
Codes (POST/Changed) are visible in the header of the OSCORE message.
The option Uri-Path ("alarm_status") and payload ("0") are encrypted. The CoAP request/response Codes are encrypted by OSCORE and only
dummy Codes (POST/Changed) are visible in the header of the OSCORE
message. The option Uri-Path ("alarm_status") and payload ("0") are
encrypted.
The COSE header of the request contains an identifier (5f), The COSE header of the request contains an identifier (5f),
indicating which security context was used to protect the message and indicating which security context was used to protect the message and
a Partial IV (42). a Partial IV (42).
The server verifies the request as specified in Section 8.2. The The server verifies the request as specified in Section 8.2. The
client verifies the response as specified in Section 8.4. client verifies the response as specified in Section 8.4.
A.2. Secure Subscribe to Sensor A.2. Secure Subscribe to Sensor
skipping to change at page 63, line 25 skipping to change at page 66, line 25
sugar measurement resource (GET /glucose), first receiving the value sugar measurement resource (GET /glucose), first receiving the value
220 mg/dl and then a second value 180 mg/dl. 220 mg/dl and then a second value 180 mg/dl.
Client Proxy Server Client Proxy Server
| | | | | |
+------>| | Code: 0.05 (FETCH) +------>| | Code: 0.05 (FETCH)
| FETCH | | Token: 0x83 | FETCH | | Token: 0x83
| | | Observe: 0 | | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15] | | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01, | | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"} | | | Uri-Path:"glucose"}
| | | | | |
| +------>| Code: 0.05 (FETCH) | +------>| Code: 0.05 (FETCH)
| | FETCH | Token: 0xbe | | FETCH | Token: 0xbe
| | | Observe: 0 | | | Observe: 0
| | | OSCORE: [kid:ca, Partial IV:15] | | | OSCORE: [kid:ca, Partial IV:15]
| | | Payload: {Code:0.01, | | | Payload: {Code:0.01,
| | | Observe:0,
| | | Uri-Path:"glucose"} | | | Uri-Path:"glucose"}
| | | | | |
| |<------+ Code: 2.05 (Content) | |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe | | 2.05 | Token: 0xbe
| | | Observe: 7 | | | Observe: 7
| | | OSCORE: [Partial IV:32] | | | OSCORE: -
| | | Payload: {Code:2.05, | | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"} | | | Content-Format:0, "220"}
| | | | | |
|<------+ | Code: 2.05 (Content) |<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83 | 2.05 | | Token: 0x83
| | | Observe: 7 | | | Observe: 7
| | | OSCORE: [Partial IV:32] | | | OSCORE: -
| | | Payload: {Code:2.05, | | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "220"} | | | Content-Format:0, "220"}
... ... ... ... ... ...
| | | | | |
| |<------+ Code: 2.05 (Content) | |<------+ Code: 2.05 (Content)
| | 2.05 | Token: 0xbe | | 2.05 | Token: 0xbe
| | | Observe: 8 | | | Observe: 8
| | | OSCORE: [Partial IV:36] | | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05, | | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"} | | | Content-Format:0, "180"}
| | | | | |
|<------+ | Code: 2.05 (Content) |<------+ | Code: 2.05 (Content)
| 2.05 | | Token: 0x83 | 2.05 | | Token: 0x83
| | | Observe: 8 | | | Observe: 8
| | | OSCORE: [Partial IV:36] | | | OSCORE: [Partial IV:36]
| | | Payload: {Code:2.05, | | | Payload: {Code:2.05,
| | | Observe:-,
| | | Content-Format:0, "180"} | | | Content-Format:0, "180"}
| | | | | |
Figure 13: Secure Subscribe to Sensor. Square brackets [ ... ] Square brackets [ ... ] indicate content of compressed COSE object
indicate content of compressed COSE object header. Curly brackets { header. Curly brackets { ... } indicate encrypted data.
... } indicate encrypted data.
Figure 13: Secure Subscribe to Sensor
The dummy Codes (FETCH/Content) are used to allow forwarding of The dummy Codes (FETCH/Content) are used to allow forwarding of
Observe messages. The options Content-Format (0) and the payload Observe messages. The options Content-Format (0) and the payload
("220" and "180"), are encrypted. ("220" and "180") are encrypted.
The COSE header of the request contains an identifier (ca), The COSE header of the request contains an identifier (ca),
indicating the security context used to protect the message and a indicating the security context used to protect the message and a
Partial IV (15). The COSE headers of the responses contains Partial Partial IV (15). The COSE header of the second response contains the
IVs (32 and 36). Partial IV (36). The first response uses the Partial IV of the
request.
The server verifies that the Partial IV has not been received before. The server verifies that the Partial IV has not been received before.
The client verifies that the responses are bound to the request and The client verifies that the responses are bound to the request and
that the Partial IVs are greater than any Partial IV previously that the Partial IVs are greater than any Partial IV previously
received in a response bound to the request. received in a response bound to the request, except for the
notification without Partial IV, which is considered the oldest.
Appendix B. Deployment Examples Appendix B. Deployment Examples
For many IoT deployments, a 128 bit uniformly random Master Key is For many Internet of Things (IoT) deployments, a 128-bit uniformly
sufficient for encrypting all data exchanged with the IoT device random Master Key is sufficient for encrypting all data exchanged
throughout its lifetime. Two examples are given in this section. In with the IoT device throughout its lifetime. Two examples are given
the first example, the security context is only derived once from the in this section. In the first example, the security context is only
Master Secret. In the second example, security contexts are derived derived once from the Master Secret. In the second example, security
multiple times using random inputs. contexts are derived multiple times using random inputs.
B.1. Security Context Derived Once B.1. Security Context Derived Once
An application that only derives the security context once needs to An application that only derives the security context once needs to
handle the loss of mutable security context parameters, e.g. due to handle the loss of mutable security context parameters, e.g., due to
reboot. reboot.
B.1.1. Sender Sequence Number B.1.1. Sender Sequence Number
In order to handle loss of Sender Sequence Numbers, the device may In order to handle loss of Sender Sequence Numbers, the device may
implement procedures for writing to non-volatile memory during normal implement procedures for writing to nonvolatile memory during normal
operations and updating the security context after reboot, provided operations and updating the security context after reboot, provided
that the procedures comply with the requirements on the security that the procedures comply with the requirements on the security
context parameters (Section 3.3). This section gives an example of context parameters (Section 3.3). This section gives an example of
such a procedure. such a procedure.
There are known issues related to writing to non-volatile memory. There are known issues related to writing to nonvolatile memory. For
For example, flash drives may have a limited number of erase example, flash drives may have a limited number of erase operations
operations during its life time. Also, the time for a write during its lifetime. Also, the time for a write operation to
operation to non-volatile memory to be completed may be nonvolatile memory to be completed may be unpredictable, e.g., due to
unpredictable, e.g. due to caching, which could result in important caching, which could result in important security context data not
security context data not being stored at the time when the device being stored at the time when the device reboots.
reboots.
However, many devices have predictable limits for writing to non- However, many devices have predictable limits for writing to
volatile memory, are physically limited to only send a small amount nonvolatile memory, are physically limited to only send a small
of messages per minute, and may have no good source of randomness. amount of messages per minute, and may have no good source of
randomness.
To prevent reuse of Sender Sequence Numbers (SSN), an endpoint may To prevent reuse of Sender Sequence Number, an endpoint may perform
perform the following procedure during normal operations: the following procedure during normal operations:
o Before using a Sender Sequence Number that is evenly divisible by o Before using a Sender Sequence Number that is evenly divisible by
K, where K is a positive integer, store the Sender Sequence Number K, where K is a positive integer, store the Sender Sequence Number
(SSN1) in non-volatile memory. After boot, the endpoint initiates (SSN1) in nonvolatile memory. After booting, the endpoint
the new Sender Sequence Number (SSN2) to the value stored in initiates the new Sender Sequence Number (SSN2) to the value
persistent memory plus K plus F: SSN2 = SSN1 + K + F, where F is a stored in persistent memory plus K plus F: SSN2 = SSN1 + K + F,
positive integer. where F is a positive integer.
* Writing to non-volatile memory can be costly; the value K gives * Writing to nonvolatile memory can be costly; the value K gives
a trade-off between frequency of storage operations and a trade-off between frequency of storage operations and
efficient use of Sender Sequence Numbers. efficient use of Sender Sequence Numbers.
* Writing to non-volatile memory may be subject to delays, or * Writing to nonvolatile memory may be subject to delays, or
failure; F MUST be set so that the last Sender Sequence Number failure; F MUST be set so that the last Sender Sequence Number
used before reboot is never larger than SSN2. used before reboot is never larger than SSN2.
If F cannot be set so SSN2 is always larger than the last Sender If F cannot be set so SSN2 is always larger than the last Sender
Sequence Number used before reboot, the method described in this Sequence Number used before reboot, the method described in this
section MUST NOT be used. section MUST NOT be used.
B.1.2. Replay Window B.1.2. Replay Window
In case of loss of security context on the server, to prevent In case of loss of security context on the server, to prevent
accepting replay of previously received requests, the server may accepting replay of previously received requests, the server may
perform the following procedure after boot: perform the following procedure after booting:
o The server updates its Sender Sequence Number as specified in o The server updates its Sender Sequence Number as specified in
Appendix B.1.1, to be used as Partial IV in the response Appendix B.1.1 to be used as Partial IV in the response containing
containing the Echo option (next bullet). the Echo option (next bullet).
o For each stored security context, the first time after boot the o For each stored security context, the first time after booting,
server receives an OSCORE request, the server responds with an the server receives an OSCORE request, the server responds with an
OSCORE protected 4.01 (Unauthorized), containing only the Echo OSCORE protected 4.01 (Unauthorized), containing only the Echo
option [I-D.ietf-core-echo-request-tag] and no diagnostic payload. option [CoAP-ECHO-REQ-TAG] and no diagnostic payload. The server
The server MUST use its Partial IV when generating the AEAD nonce MUST use its Partial IV when generating the AEAD nonce and MUST
and MUST include the Partial IV in the response (see Section 5). include the Partial IV in the response (see Section 5). If the
If the server with use of the Echo option can verify a second server with use of the Echo option can verify a second OSCORE
OSCORE request as fresh, then the Partial IV of the second request request as fresh, then the Partial IV of the second request is set
is set as the lower limit of the replay window of that security as the lower limit of the Replay Window of that security context.
context.
B.1.3. Notifications B.1.3. Notifications
To prevent accepting replay of previously received notifications, the To prevent the acceptance of replay of previously received
client may perform the following procedure after boot: notifications, the client may perform the following procedure after
booting:
o The client forgets about earlier registrations, removes all o The client forgets about earlier registrations and removes all
Notification Numbers and registers using Observe. Notification Numbers. The client then registers again using the
Observe option.
B.2. Security Context Derived Multiple Times B.2. Security Context Derived Multiple Times
An application which does not require forward secrecy may allow An application that does not require forward secrecy may allow
multiple security contexts to be derived from one Master Secret. The multiple security contexts to be derived from one Master Secret. The
requirements on the security context parameters MUST be fulfilled requirements on the security context parameters MUST be fulfilled
(Section 3.3) even if the client or server is rebooted, (Section 3.3) even if the client or server is rebooted,
recommissioned or in error cases. recommissioned, or in error cases.
This section gives an example of a protocol which adds randomness to This section gives an example of a protocol that adds randomness to
the ID Context parameter and uses that together with input parameters the ID Context parameter and uses that together with input parameters
pre-established between client and server, in particular Master preestablished between client and server, in particular Master
Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to Secret, Master Salt, and Sender/Recipient ID (see Section 3.2), to
derive new security contexts. The random input is transported derive new security contexts. The random input is transported
between client and server in the 'kid context' parameter. This between client and server in the 'kid context' parameter. This
protocol MUST NOT be used unless both endpoints have good sources of protocol MUST NOT be used unless both endpoints have good sources of
randomness. randomness.
During normal requests the ID Context of an established security During normal requests, the ID Context of an established security
context may be sent in the 'kid context' which, together with 'kid', context may be sent in the 'kid context', which, together with 'kid',
facilitates for the server to locate a security context. facilitates for the server to locate a security context.
Alternatively, the 'kid context' may be omitted since the ID Context Alternatively, the 'kid context' may be omitted since the ID Context
is expected to be known to both client and server, see Section 5.1. is expected to be known to both client and server; see Section 5.1.
The protocol described in this section may only be needed when the The protocol described in this section may only be needed when the
mutable part of security context is lost in the client or server, mutable part of security context is lost in the client or server,
e.g. when the endpoint has rebooted. The protocol may additionally e.g., when the endpoint has rebooted. The protocol may additionally
be used whenever the client and server need to derive a new security be used whenever the client and server need to derive a new security
context. For example, if a device is provisioned with one fixed set context. For example, if a device is provisioned with one fixed set
of input parameters (including Master Secret, Sender and Recipient of input parameters (including Master Secret, Sender and Recipient
Identifiers) then a randomized ID Context ensures that the security Identifiers), then a randomized ID Context ensures that the security
context is different for each deployment. context is different for each deployment.
Note that the server needs to be configured to run this protocol when
it is not able to retrieve an existing security context, instead of
stopping processing the message as described in step 2 of
Section 8.2.
The protocol is described below with reference to Figure 14. The The protocol is described below with reference to Figure 14. The
client or the server may initiate the protocol, in the latter case client or the server may initiate the protocol, in the latter case
step 1 is omitted. step 1 is omitted.
Client Server Client Server
| | | |
1. Protect with | request #1 | 1. Protect with | request #1 |
ID Context = ID1 |--------------------->| 2. Verify with ID Context = ID1 |--------------------->| 2. Verify with
| kid_context = ID1 | ID Context = ID1 | kid_context = ID1 | ID Context = ID1
| | | |
skipping to change at page 67, line 33 skipping to change at page 71, line 23
ID Context = R2||ID1 | kid_context = R2 | ID Context = R2||ID1 | kid_context = R2 |
| | | |
Protect with | request #2 | Protect with | request #2 |
ID Context = R2||R3 |--------------------->| 4. Verify with ID Context = R2||R3 |--------------------->| 4. Verify with
| kid_context = R2||R3 | ID Context = R2||R3 | kid_context = R2||R3 | ID Context = R2||R3
| | | |
| response #2 | Protect with | response #2 | Protect with
5. Verify with |<---------------------| ID Context = R2||R3 5. Verify with |<---------------------| ID Context = R2||R3
ID Context = R2||R3 | | ID Context = R2||R3 | |
Figure 14: Protocol for establishing a new security context. Figure 14: Protocol for Establishing a New Security Context
1. (Optional) If the client does not have a valid security context 1. (Optional) If the client does not have a valid security context
with the server, e.g. because of reboot or because this is the with the server, e.g., because of reboot or because this is the
first time it contacts the server, then it generates a random first time it contacts the server, then it generates a random
string R1, and uses this as ID Context together with the input string R1 and uses this as ID Context together with the input
parameters shared with the server to derive a first security parameters shared with the server to derive a first security
context. The client sends an OSCORE request to the server context. The client sends an OSCORE request to the server
protected with the first security context, containing R1 wrapped protected with the first security context, containing R1 wrapped
in a CBOR bstr as 'kid context'. The request may target a in a CBOR bstr as 'kid context'. The request may target a
special resource used for updating security contexts. special resource used for updating security contexts.
2. The server receives an OSCORE request for which it does not have 2. The server receives an OSCORE request for which it does not have
a valid security context, either because the client has generated a valid security context, either because the client has generated
a new security context ID1 = R1, or because the server has lost a new security context ID1 = R1 or because the server has lost
part of its security context, e.g. ID Context, Sender Sequence part of its security context, e.g., ID Context, Sender Sequence
Number or replay window. If the server is able to verify the Number or Replay Window. If the server is able to verify the
request (see Section 8.2) with the new derived first security request (see Section 8.2) with the new derived first security
context using the received ID1 (transported in 'kid context') as context using the received ID1 (transported in 'kid context') as
ID Context and the input parameters associated to the received ID Context and the input parameters associated to the received
'kid', then the server generates a random string R2, and derives 'kid', then the server generates a random string R2 and derives a
a second security context with ID Context = ID2 = R2 || ID1. The second security context with ID Context = ID2 = R2 || ID1. The
server sends a 4.01 (Unauthorized) response protected with the server sends a 4.01 (Unauthorized) response protected with the
second security context, containing R2 wrapped in a CBOR bstr as second security context, containing R2 wrapped in a CBOR bstr as
'kid context', and caches R2. R2 MUST NOT be reused as that may 'kid context', and caches R2. R2 MUST NOT be reused as that may
lead to reuse of key and nonce in reponse #1. Note that the lead to reuse of key and nonce in response #1. Note that the
server may receive several requests #1 associated with one server may receive several requests #1 associated with one
security context, leading to multiple parallel protocol runs. security context, leading to multiple parallel protocol runs.
Multiple instances of R2 may need to be cached until one of the Multiple instances of R2 may need to be cached until one of the
protocol runs is completed, see Appendix B.2.1. protocol runs is completed, see Appendix B.2.1.
3. The client receives a response with 'kid context' containing a 3. The client receives a response with 'kid context' containing a
CBOR bstr wrapping R2 to an OSCORE request it made with ID CBOR bstr wrapping R2 to an OSCORE request it made with ID
Context = ID1. The client derives a second security context Context = ID1. The client derives a second security context
using ID Context = ID2 = R2 || ID1. If the client can verify the using ID Context = ID2 = R2 || ID1. If the client can verify the
response (see Section 8.4) using the second security context, response (see Section 8.4) using the second security context,
then the client makes a request protected with a third security then the client makes a request protected with a third security
context derived from ID Context = ID3 = R2 || R3, where R3 is a context derived from ID Context = ID3 = R2 || R3, where R3 is a
random byte string generated by the client. The request includes random byte string generated by the client. The request includes
R2 || R3 wrapped in a CBOR bstr as 'kid context'. R2 || R3 wrapped in a CBOR bstr as 'kid context'.
4. If the server receives a request with 'kid context' containing a 4. If the server receives a request with 'kid context' containing a
CBOR bstr wrapping ID3, where the first part of ID3 is identical CBOR bstr wrapping ID3, where the first part of ID3 is identical
to an R2 sent in a previous response #1 which it has not received to an R2 sent in a previous response #1, which it has not
before, then the server derives a third security context with ID received before, then the server derives a third security context
Context = ID3. The server MUST NOT accept replayed request #2 with ID Context = ID3. The server MUST NOT accept replayed
messages. If the server can verify the request (see Section 8.2) request #2 messages. If the server can verify the request (see
with the third security context, then the server marks the third Section 8.2) with the third security context, then the server
security context to be used with this client and removes all marks the third security context to be used with this client and
instances of R2 associated to this security context from the removes all instances of R2 associated to this security context
cache. This security context replaces the previous security from the cache. This security context replaces the previous
context with the client, and the first and the second security security context with the client, and the first and the second
contexts are deleted. The server responds using the same security contexts are deleted. The server responds using the
security context as in the request. same security context as in the request.
5. If the client receives a response to the request with the third 5. If the client receives a response to the request with the third
security context and the response verifies (see Section 8.4), security context and the response verifies (see Section 8.4),
then the client marks the third security context to be used with then the client marks the third security context to be used with
this server. This security context replaces the previous this server. This security context replaces the previous
security context with the server, and the first and second security context with the server, and the first and second
security contexts are deleted. security contexts are deleted.
If verification fails in any step, the endpoint stops processing that If verification fails in any step, the endpoint stops processing that
message. message.
The length of the nonces R1, R2, and R3 is application specific. The The length of the nonces R1, R2, and R3 is application specific. The
application needs to set the length of each nonce such the application needs to set the length of each nonce such that the
probability of its value being repeated is negligible; typically, at probability of its value being repeated is negligible; typically, at
least 8 bytes long. Since R2 may be generated as the result of a least 8 bytes long. Since R2 may be generated as the result of a
replayed request #1, the probability for collision of R2s is impacted replayed request #1, the probability for collision of R2s is impacted
by the birthday paradox. For example, setting the length of R2 to 8 by the birthday paradox. For example, setting the length of R2 to 8
bytes results in an average collision after 2^32 response #1 bytes results in an average collision after 2^32 response #1
messages, which should not be an issue for a constrained server messages, which should not be an issue for a constrained server
handling on the order of one request per second. handling on the order of one request per second.
Request #2 can be an ordinary request. The server performs the Request #2 can be an ordinary request. The server performs the
action of the request and sends response #2 after having successfully action of the request and sends response #2 after having successfully
completed the security context related operations in step 4. The completed the operations related to the security context in step 4.
client acts on response #2 after having successfully completed step The client acts on response #2 after having successfully completed
5. step 5.
When sending request #2, the client is assured that the Sender Key When sending request #2, the client is assured that the Sender Key
(derived with the random value R3) has never been used before. When (derived with the random value R3) has never been used before. When
receiving response #2, the client is assured that the response receiving response #2, the client is assured that the response
(protected with a key derived from the random value R3 and the Master (protected with a key derived from the random value R3 and the Master
Secret) was created by the server in response to request #2. Secret) was created by the server in response to request #2.
Similarly, when receiving request #2, the server is assured that the Similarly, when receiving request #2, the server is assured that the
request (protected with a key derived from the random value R2 and request (protected with a key derived from the random value R2 and
the Master Secret) was created by the client in response to response the Master Secret) was created by the client in response to response
#1. When sending response #2, the server is assured that the Sender #1. When sending response #2, the server is assured that the Sender
Key (derived with the random value R2) has never been used before. Key (derived with the random value R2) has never been used before.
Implementation and denial-of-service considerations are made in Implementation and denial-of-service considerations are made in
Appendix B.2.1 and Appendix B.2.2. Appendix B.2.1 and Appendix B.2.2.
B.2.1. Implementation Considerations B.2.1. Implementation Considerations
This section add some implemention considerations to the protocol This section add some implementation considerations to the protocol
described in the previous section. described in the previous section.
The server may only have space for a few security contexts, or only The server may only have space for a few security contexts or only be
be able to handle a few protocol runs in parallel. The server may able to handle a few protocol runs in parallel. The server may
legitimately receive multiple request #1 messages using the same non- legitimately receive multiple request #1 messages using the same
mutable security context, e.g. due to packet loss. Replays of old immutable security context, e.g., because of packet loss. Replays of
request #1 messages could be difficult for the server to distinguish old request #1 messages could be difficult for the server to
from legitimate. The server needs to handle the case when the distinguish from legitimate. The server needs to handle the case
maximum number of cached R2s is reached. If the server receives a when the maximum number of cached R2s is reached. If the server
request #1 and is not capable of executing it then it may respond receives a request #1 and is not capable of executing it then it may
with an unprotected 5.03 (Service Unavailable). The server may clear respond with an unprotected 5.03 (Service Unavailable) error message.
up state from protocol runs which never complete, e.g. set a timer The server may clear up state from protocol runs that never complete,
when caching R2, and remove R2 and the associated security contexts e.g., set a timer when caching R2, and remove R2 and the associated
from the cache at timeout. Additionally, state information can be security contexts from the cache at timeout. Additionally, state
flushed at reboot. information can be flushed at reboot.
As an alternative to caching R2, the server could generate R2 in such As an alternative to caching R2, the server could generate R2 in such
a way that it can be sent (in response #1) and verified (at reception a way that it can be sent (in response #1) and verified (at reception
of request #2) as the value of R2 it had generated. Such a procedure of request #2) as the value of R2 it had generated. Such a procedure
MUST NOT lead to the server accepting replayed request #2 messages. MUST NOT lead to the server accepting replayed request #2 messages.
One construction described in the following is based on using a One construction described in the following is based on using a
secret random HMAC key K_HMAC per set of non-mutable security context secret random HMAC key K_HMAC per set of immutable security context
parameters associated to a client. This construction allows the parameters associated with a client. This construction allows the
server to handle verification of R2 in response #2 at the cost of server to handle verification of R2 in response #2 at the cost of
storing the K_HMAC keys and a slightly larger message overhead in storing the K_HMAC keys and a slightly larger message overhead in
response #1. Steps below refer to modifications to Appendix B.2: response #1. Steps below refer to modifications to Appendix B.2:
o In step 2, R2 is generated in the following way. First, the o In step 2, R2 is generated in the following way. First, the
server generates a random K_HMAC (unless it already has one server generates a random K_HMAC (unless it already has one
associated with the security context), then it sets R2 = S2 || associated with the security context), then it sets R2 = S2 ||
HMAC(K_HMAC, S2) where S2 is a random byte string, and the HMAC is HMAC(K_HMAC, S2) where S2 is a random byte string, and the HMAC is
truncated to 8 bytes. K_HMAC may have an expiration time, after truncated to 8 bytes. K_HMAC may have an expiration time, after
which it is erased. Note that neither R2, S2 nor the derived which it is erased. Note that neither R2, S2, nor the derived
first and second security contexts need to be cached. first and second security contexts need to be cached.
o In step 4, instead of verifying that R2 coincides with a cached o In step 4, instead of verifying that R2 coincides with a cached
value, the server looks up the associated K_HMAC and verifies the value, the server looks up the associated K_HMAC and verifies the
truncated HMAC, and the processing continues accordingly depending truncated HMAC, and the processing continues accordingly depending
on verification success or failure. K_HMAC is used until a run of on verification success or failure. K_HMAC is used until a run of
the protocol is completed (after verification of request #2), or the protocol is completed (after verification of request #2), or
until it expires (whatever comes first), after which K_HMAC is until it expires (whatever comes first), after which K_HMAC is
erased. (The latter corresponds to removing the cached values of erased. (The latter corresponds to removing the cached values of
R2 in step 4 of Appendix B.2, and makes the server reject replays R2 in step 4 of Appendix B.2 and makes the server reject replays
of request #2.) of request #2.)
The length of S2 is application specific and the probability for The length of S2 is application specific and the probability for
collision of S2s is impacted by the birthday paradox. For example, collision of S2s is impacted by the birthday paradox. For example,
setting the length of S2 to 8 bytes results in an average collision setting the length of S2 to 8 bytes results in an average collision
after 2^32 response #1 messages, which should not be an issue for a after 2^32 response #1 messages, which should not be an issue for a
constrained server handling on the order of one request per second. constrained server handling on the order of one request per second.
Two endpoints sharing a security context may accidently initiate two Two endpoints sharing a security context may accidentally initiate
instances of the protocol at the same time, each in the role of two instances of the protocol at the same time, each in the role of
client, e.g. after a power outage affecting both endpoints. Such a client, e.g., after a power outage affecting both endpoints. Such a
race condition could potentially lead to both protocols failing, and race condition could potentially lead to both protocols failing, and
both endpoints repeatedly re-initiating the protocol without both endpoints repeatedly reinitiating the protocol without
converging. Both endpoints can detect this situation and it can be converging. Both endpoints can detect this situation, and it can be
handled in different ways. The requests could potentially be more handled in different ways. The requests could potentially be more
spread out in time, for example by only initiating this protocol when spread out in time, for example, by only initiating this protocol
the endpoint actually needs to make a request, potentially adding a when the endpoint actually needs to make a request, potentially
random delay before requests immediately after reboot or if such adding a random delay before requests immediately after reboot or if
parallel protocol runs are detected. such parallel protocol runs are detected.
B.2.2. Attack Considerations B.2.2. Attack Considerations
An on-path attacker may inject a message causing the endpoint to An on-path attacker may inject a message causing the endpoint to
process verification of the message. A message crafted without process verification of the message. A message crafted without
access to the Master Secret will fail to verify. access to the Master Secret will fail to verify.
Replaying an old request with a value of 'kid_context' which the Replaying an old request with a value of 'kid_context' that the
server does not recognize could trigger the protocol. This causes server does not recognize could trigger the protocol. This causes
the server to generate the first and second security context and send the server to generate the first and second security context and send
a response. But if the client did not expect a response it will be a response. But if the client did not expect a response, it will be
discarded. This may still result in a denial-of-service attack discarded. This may still result in a denial-of-service attack
against the server e.g. because of not being able to manage the state against the server, e.g., because of not being able to manage the
associated with many parallel protocol runs, and it may prevent state associated with many parallel protocol runs, and it may prevent
legitimate client requests. Implementation alternatives with less legitimate client requests. Implementation alternatives with less
data caching per request #1 message are favorable in this respect, data caching per request #1 message are favorable in this respect;
see Appendix B.2.1. see Appendix B.2.1.
Replaying response #1 in response to some request other than request Replaying response #1 in response to some request other than request
#1 will fail to verify, since response #1 is associated to request #1 will fail to verify, since response #1 is associated to request
#1, through the dependencies of ID Contexts and the Partial IV of #1, through the dependencies of ID Contexts and the Partial IV of
request #1 included in the external_aad of response #1. request #1 included in the external_aad of response #1.
If request #2 has already been well received, then the server has a If request #2 has already been well received, then the server has a
valid security context, so a replay of request #2 is handled by the valid security context, so a replay of request #2 is handled by the
normal replay protection mechanism. Similarly if response #2 has normal replay protection mechanism. Similarly, if response #2 has
already been received, a replay of response #2 to some other request already been received, a replay of response #2 to some other request
from the client will fail by the normal verification of binding of from the client will fail by the normal verification of binding of
response to request. response to request.
Appendix C. Test Vectors Appendix C. Test Vectors
This appendix includes the test vectors for different examples of This appendix includes the test vectors for different examples of
CoAP messages using OSCORE. Given a set of inputs, OSCORE defines CoAP messages using OSCORE. Given a set of inputs, OSCORE defines
how to set up the Security Context in both the client and the server. how to set up the Security Context in both the client and the server.
Note that in Appendix C.4 and all following test vectors the Token Note that in Appendix C.4 and all following test vectors the Token
and the Message ID of the OSCORE-protected CoAP messages are set to and the Message ID of the OSCORE-protected CoAP messages are set to
the same value of the unprotected CoAP message, to help the reader the same value of the unprotected CoAP message to help the reader
with comparisons. with comparisons.
[NOTE: the following examples use option number = 9 (TBD1 assigned by
IANA). If that differs, the RFC editor is asked to update the test
vectors with data provided by the authors. Please remove this
paragraph before publication.]
C.1. Test Vector 1: Key Derivation with Master Salt C.1. Test Vector 1: Key Derivation with Master Salt
In this test vector, a Master Salt of 8 bytes is used. The default In this test vector, a Master Salt of 8 bytes is used. The default
values are used for AEAD Algorithm and HKDF. values are used for AEAD Algorithm and HKDF.
C.1.1. Client C.1.1. Client
Inputs: Inputs:
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
skipping to change at page 75, line 4 skipping to change at page 78, line 35
o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes) o Sender Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes)
o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o Recipient Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes) o Common IV: 0xbe35ae297d2dace910c52e99f9 (13 bytes)
From the previous parameters and a Partial IV equal to 0 (both for From the previous parameters and a Partial IV equal to 0 (both for
sender and recipient): sender and recipient):
o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes) o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes) o recipient nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
C.3. Test Vector 3: Key Derivation with ID Context C.3. Test Vector 3: Key Derivation with ID Context
In this test vector, a Master Salt of 8 bytes and a ID Context of 8 In this test vector, a Master Salt of 8 bytes and an ID Context of 8
bytes are used. The default values are used for AEAD Algorithm and bytes are used. The default values are used for AEAD Algorithm and
HKDF. HKDF.
C.3.1. Client C.3.1. Client
Inputs: Inputs:
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Master Salt: 0x9e7ca92223786340 (8 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes)
skipping to change at page 76, line 47 skipping to change at page 80, line 28
From the previous parameters and a Partial IV equal to 0 (both for From the previous parameters and a Partial IV equal to 0 (both for
sender and recipient): sender and recipient):
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes) o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes) o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
C.4. Test Vector 4: OSCORE Request, Client C.4. Test Vector 4: OSCORE Request, Client
This section contains a test vector for an OSCORE protected CoAP GET This section contains a test vector for an OSCORE-protected CoAP GET
request using the security context derived in Appendix C.1. The request using the security context derived in Appendix C.1. The
unprotected request only contains the Uri-Path and Uri-Host options. unprotected request only contains the Uri-Path and Uri-Host options.
Unprotected CoAP request: Unprotected CoAP request:
0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes) 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
Common Context: Common Context:
o AEAD Algorithm: 10 (AES-CCM-16-64-128) o AEAD Algorithm: 10 (AES-CCM-16-64-128)
o Key Derivation Function: HKDF SHA-256 o Key Derivation Function: HKDF SHA-256
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
Sender Context: Sender Context:
skipping to change at page 77, line 19 skipping to change at page 81, line 4
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes)
Sender Context: Sender Context:
o Sender ID: 0x (0 byte) o Sender ID: 0x (0 byte)
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes) o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Sender Sequence Number: 20 o Sender Sequence Number: 20
The following COSE and cryptographic parameters are derived: The following COSE and cryptographic parameters are derived:
o Partial IV: 0x14 (1 byte) o Partial IV: 0x14 (1 byte)
o kid: 0x (0 byte) o kid: 0x (0 byte)
o external_aad: 0x8501810a40411440 (8 bytes) o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x01b3747631 (5 bytes) o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes) o encryption key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes) o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
skipping to change at page 77, line 49 skipping to change at page 81, line 33
o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes) o ciphertext: 0x612f1092f1776f1c1668b3825e (13 bytes)
From there: From there:
o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6 o Protected CoAP request (OSCORE message): 0x44025d1f00003974396c6f6
3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes) 3616c686f7374620914ff612f1092f1776f1c1668b3825e (35 bytes)
C.5. Test Vector 5: OSCORE Request, Client C.5. Test Vector 5: OSCORE Request, Client
This section contains a test vector for an OSCORE protected CoAP GET This section contains a test vector for an OSCORE-protected CoAP GET
request using the security context derived in Appendix C.2. The request using the security context derived in Appendix C.2. The
unprotected request only contains the Uri-Path and Uri-Host options. unprotected request only contains the Uri-Path and Uri-Host options.
Unprotected CoAP request: Unprotected CoAP request:
0x440171c30000b932396c6f63616c686f737483747631 (22 bytes) 0x440171c30000b932396c6f63616c686f737483747631 (22 bytes)
Common Context: Common Context:
o AEAD Algorithm: 10 (AES-CCM-16-64-128) o AEAD Algorithm: 10 (AES-CCM-16-64-128)
skipping to change at page 78, line 30 skipping to change at page 82, line 14
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Sender Sequence Number: 20 o Sender Sequence Number: 20
The following COSE and cryptographic parameters are derived: The following COSE and cryptographic parameters are derived:
o Partial IV: 0x14 (1 byte) o Partial IV: 0x14 (1 byte)
o kid: 0x00 (1 byte) o kid: 0x00 (1 byte)
o external_aad: 0x8501810a4100411440 (9 bytes) o aad_array: 0x8501810a4100411440 (9 bytes)
o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes) o AAD: 0x8368456e63727970743040498501810a4100411440 (21 bytes)
o plaintext: 0x01b3747631 (5 bytes) o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o encryption key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes) o nonce: 0xbf35ae297d2dace910c52e99ed (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
skipping to change at page 79, line 7 skipping to change at page 82, line 37
o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes) o ciphertext: 0x4ed339a5a379b0b8bc731fffb0 (13 bytes)
From there: From there:
o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6 o Protected CoAP request (OSCORE message): 0x440271c30000b932396c6f6
3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes) 3616c686f737463091400ff4ed339a5a379b0b8bc731fffb0 (36 bytes)
C.6. Test Vector 6: OSCORE Request, Client C.6. Test Vector 6: OSCORE Request, Client
This section contains a test vector for an OSCORE protected CoAP GET This section contains a test vector for an OSCORE-protected CoAP GET
request for an application that sets the ID Context and requires it request for an application that sets the ID Context and requires it
to be sent in the request, so 'kid context' is present in the to be sent in the request, so 'kid context' is present in the
protected message. This test vector uses the security context protected message. This test vector uses the security context
derived in Appendix C.3. The unprotected request only contains the derived in Appendix C.3. The unprotected request only contains the
Uri-Path and Uri-Host options. Uri-Path and Uri-Host options.
Unprotected CoAP request: Unprotected CoAP request:
0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes) 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes)
Common Context: Common Context:
skipping to change at page 79, line 43 skipping to change at page 83, line 24
o Sender Sequence Number: 20 o Sender Sequence Number: 20
The following COSE and cryptographic parameters are derived: The following COSE and cryptographic parameters are derived:
o Partial IV: 0x14 (1 byte) o Partial IV: 0x14 (1 byte)
o kid: 0x (0 byte) o kid: 0x (0 byte)
o kid context: 0x37cbf3210017a2d3 (8 bytes) o kid context: 0x37cbf3210017a2d3 (8 bytes)
o external_aad: 0x8501810a40411440 (8 bytes) o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x01b3747631 (5 bytes) o plaintext: 0x01b3747631 (5 bytes)
o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes) o encryption key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes) o nonce: 0x2ca58fb85ff1b81c0b7181b84a (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes) o OSCORE option value: 0x19140837cbf3210017a2d3 (11 bytes)
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes) o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
From there: From there:
o Protected CoAP request (OSCORE message): o Protected CoAP request (OSCORE message):
0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff
skipping to change at page 80, line 18 skipping to change at page 84, line 7
o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes) o ciphertext: 0x72cd7273fd331ac45cffbe55c3 (13 bytes)
From there: From there:
o Protected CoAP request (OSCORE message): o Protected CoAP request (OSCORE message):
0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff
72cd7273fd331ac45cffbe55c3 (44 bytes) 72cd7273fd331ac45cffbe55c3 (44 bytes)
C.7. Test Vector 7: OSCORE Response, Server C.7. Test Vector 7: OSCORE Response, Server
This section contains a test vector for an OSCORE protected 2.05 This section contains a test vector for an OSCORE-protected 2.05
(Content) response to the request in Appendix C.4. The unprotected (Content) response to the request in Appendix C.4. The unprotected
response has payload "Hello World!" and no options. The protected response has payload "Hello World!" and no options. The protected
response does not contain a 'kid' nor a Partial IV. Note that some response does not contain a 'kid' nor a Partial IV. Note that some
parameters are derived from the request. parameters are derived from the request.
Unprotected CoAP response: Unprotected CoAP response:
0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes) 0x64455d1f00003974ff48656c6c6f20576f726c6421 (21 bytes)
Common Context: Common Context:
skipping to change at page 80, line 45 skipping to change at page 84, line 34
Sender Context: Sender Context:
o Sender ID: 0x01 (1 byte) o Sender ID: 0x01 (1 byte)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Sequence Number: 0 o Sender Sequence Number: 0
The following COSE and cryptographic parameters are derived: The following COSE and cryptographic parameters are derived:
o external_aad: 0x8501810a40411440 (8 bytes) o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes) o nonce: 0x4622d4dd6d944168eefb549868 (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
o OSCORE option value: 0x (0 bytes) o OSCORE option value: 0x (0 bytes)
o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22 o ciphertext: 0xdbaad1e9a7e7b2a813d3c31524378303cdafae119106 (22
bytes) bytes)
From there: From there:
skipping to change at page 81, line 50 skipping to change at page 85, line 42
o Sender ID: 0x01 (1 byte) o Sender ID: 0x01 (1 byte)
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Sender Sequence Number: 0 o Sender Sequence Number: 0
The following COSE and cryptographic parameters are derived: The following COSE and cryptographic parameters are derived:
o Partial IV: 0x00 (1 byte) o Partial IV: 0x00 (1 byte)
o external_aad: 0x8501810a40411440 (8 bytes) o aad_array: 0x8501810a40411440 (8 bytes)
o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes) o AAD: 0x8368456e63727970743040488501810a40411440 (20 bytes)
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o encryption key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes) o nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
o OSCORE option value: 0x0100 (2 bytes) o OSCORE option value: 0x0100 (2 bytes)
o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22 o ciphertext: 0x4d4c13669384b67354b2b6175ff4b8658c666a6cf88e (22
bytes) bytes)
From there: From there:
o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100 o Protected CoAP response (OSCORE message): 0x64445d1f00003974920100
skipping to change at page 82, line 34 skipping to change at page 86, line 26
Appendix D. Overview of Security Properties Appendix D. Overview of Security Properties
D.1. Threat Model D.1. Threat Model
This section describes the threat model using the terms of [RFC3552]. This section describes the threat model using the terms of [RFC3552].
It is assumed that the endpoints running OSCORE have not themselves It is assumed that the endpoints running OSCORE have not themselves
been compromised. The attacker is assumed to have control of the been compromised. The attacker is assumed to have control of the
CoAP channel over which the endpoints communicate, including CoAP channel over which the endpoints communicate, including
intermediary nodes. The attacker is capable of launching any passive intermediary nodes. The attacker is capable of launching any passive
or active, on-path or off-path attacks; including eavesdropping, or active on-path or off-path attacks; including eavesdropping,
traffic analysis, spoofing, insertion, modification, deletion, delay, traffic analysis, spoofing, insertion, modification, deletion, delay,
replay, man-in-the-middle, and denial-of-service attacks. This means replay, man-in-the-middle, and denial-of-service attacks. This means
that the attacker can read any CoAP message on the network and that the attacker can read any CoAP message on the network and
undetectably remove, change, or inject forged messages onto the wire. undetectably remove, change, or inject forged messages onto the wire.
OSCORE targets the protection of the CoAP request/response layer OSCORE targets the protection of the CoAP request/response layer
(Section 2 of [RFC7252]) between the endpoints, including the CoAP (Section 2 of [RFC7252]) between the endpoints, including the CoAP
Payload, Code, Uri-Path/Uri-Query, and the other Class E option Payload, Code, Uri-Path/Uri-Query, and the other Class E option
instances (Section 4.1). instances (Section 4.1).
OSCORE does not protect the CoAP messaging layer (Section 2 of OSCORE does not protect the CoAP messaging layer (Section 2 of
[RFC7252]) or other lower layers involved in routing and transporting [RFC7252]) or other lower layers involved in routing and transporting
the CoAP requests and responses. the CoAP requests and responses.
Additionally, OSCORE does not protect Class U option instances Additionally, OSCORE does not protect Class U option instances
(Section 4.1), as these are used to support CoAP forward proxy (Section 4.1), as these are used to support CoAP forward proxy
operations (see Section 5.7.2 of [RFC7252]). The supported proxies operations (see Section 5.7.2 of [RFC7252]). The supported proxies
(forwarding, cross-protocol e.g. CoAP to CoAP-mappable protocols (forwarding, cross-protocol, e.g., CoAP to CoAP-mappable protocols
such as HTTP) must be able to change certain Class U options (by such as HTTP) must be able to change certain Class U options (by
instruction from the Client), resulting in the CoAP request being instruction from the Client), resulting in the CoAP request being
redirected to the server. Changes caused by the proxy may result in redirected to the server. Changes caused by the proxy may result in
the request not reaching the server or reaching the wrong server. the request not reaching the server or reaching the wrong server.
For cross-protocol proxies, mappings are done on the Outer part of For cross-protocol proxies, mappings are done on the Outer part of
the message so these protocols are essentially used as transport. the message so these protocols are essentially used as transport.
Manipulation of these options may thus impact whether the protected Manipulation of these options may thus impact whether the protected
message reaches or does not reach the destination endpoint. message reaches or does not reach the destination endpoint.
Attacks on unprotected CoAP message fields generally causes denial- Attacks on unprotected CoAP message fields generally causes denial-
skipping to change at page 83, line 29 skipping to change at page 87, line 23
is intended to protect against eavesdropping, spoofing, insertion, is intended to protect against eavesdropping, spoofing, insertion,
modification, deletion, replay, and man-in-the middle attacks. modification, deletion, replay, and man-in-the middle attacks.
OSCORE is susceptible to traffic analysis as discussed later in OSCORE is susceptible to traffic analysis as discussed later in
Appendix D. Appendix D.
D.2. Supporting Proxy Operations D.2. Supporting Proxy Operations
CoAP is designed to work with intermediaries reading and/or changing CoAP is designed to work with intermediaries reading and/or changing
CoAP message fields to perform supporting operations in constrained CoAP message fields to perform supporting operations in constrained
environments, e.g. forwarding and cross-protocol translations. environments, e.g., forwarding and cross-protocol translations.
Securing CoAP on transport layer protects the entire message between Securing CoAP on the transport layer protects the entire message
the endpoints in which case CoAP proxy operations are not possible. between the endpoints, in which case CoAP proxy operations are not
In order to enable proxy operations, security on transport layer possible. In order to enable proxy operations, security on the
needs to be terminated at the proxy in which case the CoAP message in transport layer needs to be terminated at the proxy; in which case,
its entirety is unprotected in the proxy. the CoAP message in its entirety is unprotected in the proxy.
Requirements for CoAP end-to-end security are specified in Requirements for CoAP end-to-end security are specified in
[I-D.hartke-core-e2e-security-reqs], in particular forwarding is [CoAP-E2E-Sec], in particular, forwarding is detailed in
detailed in Section 2.2.1. The client and server are assumed to be Section 2.2.1. The client and server are assumed to be honest, while
honest, while proxies and gateways are only trusted to perform their proxies and gateways are only trusted to perform their intended
intended operations. operations.
By working at the CoAP layer, OSCORE enables different CoAP message By working at the CoAP layer, OSCORE enables different CoAP message
fields to be protected differently, which allows message fields fields to be protected differently, which allows message fields
required for proxy operations to be available to the proxy while required for proxy operations to be available to the proxy while
message fields intended for the other endpoint remain protected. In message fields intended for the other endpoint remain protected. In
the remainder of this section we analyze how OSCORE protects the the remainder of this section, we analyze how OSCORE protects the
protected message fields and the consequences of message fields protected message fields and the consequences of message fields
intended for proxy operation being unprotected. intended for proxy operation being unprotected.
D.3. Protected Message Fields D.3. Protected Message Fields
Protected message fields are included in the Plaintext (Section 5.3) Protected message fields are included in the plaintext (Section 5.3)
and the Additional Authenticated Data (Section 5.4) of the and the AAD (Section 5.4) of the COSE_Encrypt0 object and encrypted
COSE_Encrypt0 object and encrypted using an AEAD algorithm. using an AEAD algorithm.
OSCORE depends on a pre-established random Master Secret OSCORE depends on a preestablished random Master Secret
(Section 12.3) used to derive encryption keys, and a construction for (Section 12.3) used to derive encryption keys, and a construction for
making (key, nonce) pairs unique (Appendix D.4). Assuming this is making (key, nonce) pairs unique (Appendix D.4). Assuming this is
true, and the keys are used for no more data than indicated in true, and the keys are used for no more data than indicated in
Section 7.2.1, OSCORE should provide the following guarantees: Section 7.2.1, OSCORE should provide the following guarantees:
o Confidentiality: An attacker should not be able to determine the o Confidentiality: An attacker should not be able to determine the
plaintext contents of a given OSCORE message or determine that plaintext contents of a given OSCORE message or determine that
different plaintexts are related (Section 5.3). different plaintexts are related (Section 5.3).
o Integrity: An attacker should not be able to craft a new OSCORE o Integrity: An attacker should not be able to craft a new OSCORE
message with protected message fields different from an existing message with protected message fields different from an existing
OSCORE message which will be accepted by the receiver. OSCORE message that will be accepted by the receiver.
o Request-response binding: An attacker should not be able to make a o Request-response binding: An attacker should not be able to make a
client match a response to the wrong request. client match a response to the wrong request.
o Non-replayability: An attacker should not be able to cause the o Non-replayability: An attacker should not be able to cause the
receiver to accept a message which it has previously received and receiver to accept a message that it has previously received and
accepted. accepted.
In the above, the attacker is anyone except the endpoints, e.g. a In the above, the attacker is anyone except the endpoints, e.g., a
compromised intermediary. Informally, OSCORE provides these compromised intermediary. Informally, OSCORE provides these
properties by AEAD-protecting the plaintext with a strong key and properties by AEAD-protecting the plaintext with a strong key and
uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides
confidentiality and integrity for the data. Response-request binding confidentiality and integrity for the data. Response-request binding
is provided by including the 'kid' and Partial IV of the request in is provided by including the 'kid' and Partial IV of the request in
the AAD of the response. Non-replayability of requests and the AAD of the response. Non-replayability of requests and
notifications is provided by using unique (key, nonce) pairs and a notifications is provided by using unique (key, nonce) pairs and a
replay protection mechanism (application dependent, see Section 7.4). replay protection mechanism (application dependent, see Section 7.4).
OSCORE is susceptible to a variety of traffic analysis attacks based OSCORE is susceptible to a variety of traffic analysis attacks based
on observing the length and timing of encrypted packets. OSCORE does on observing the length and timing of encrypted packets. OSCORE does
not provide any specific defenses against this form of attack but the not provide any specific defenses against this form of attack, but
application may use a padding mechanism to prevent an attacker from the application may use a padding mechanism to prevent an attacker
directly determine the length of the padding. However, information from directly determining the length of the padding. However,
about padding may still be revealed by side-channel attacks observing information about padding may still be revealed by side-channel
differences in timing. attacks observing differences in timing.
D.4. Uniqueness of (key, nonce) D.4. Uniqueness of (key, nonce)
In this section we show that (key, nonce) pairs are unique as long as In this section, we show that (key, nonce) pairs are unique as long
the requirements in Sections 3.3 and 7.2.1 are followed. as the requirements in Sections 3.3 and 7.2.1 are followed.
Fix a Common Context (Section 3.1) and an endpoint, called the Fix a Common Context (Section 3.1) and an endpoint, called the
encrypting endpoint. An endpoint may alternate between client and encrypting endpoint. An endpoint may alternate between client and
server roles, but each endpoint always encrypts with the Sender Key server roles, but each endpoint always encrypts with the Sender Key
of its Sender Context. Sender Keys are (stochastically) unique since of its Sender Context. Sender Keys are (stochastically) unique since
they are derived with HKDF using unique Sender IDs, so messages they are derived with HKDF using unique Sender IDs, so messages
encrypted by different endpoints use different keys. It remains to encrypted by different endpoints use different keys. It remains to
prove that the nonces used by the fixed endpoint are unique. be proven that the nonces used by the fixed endpoint are unique.
Since the Common IV is fixed, the nonces are determined by a Partial Since the Common IV is fixed, the nonces are determined by PIV, where
IV (PIV) and the Sender ID of the endpoint generating that Partial IV PIV takes the value of the Partial IV of the request or of the
(ID_PIV). The nonce construction (Section 5.2) with the size of the response, and by the Sender ID of the endpoint generating that
ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs. Partial IV (ID_PIV). The nonce construction (Section 5.2) with the
There are two cases: size of the ID_PIV (S) creates unique nonces for different (ID_PIV,
PIV) pairs. There are two cases:
A. For requests, and responses with Partial IV (e.g. Observe A. For requests, and responses with Partial IV (e.g., Observe
notifications): notifications):
o ID_PIV = Sender ID of the encrypting endpoint o ID_PIV = Sender ID of the encrypting endpoint
o PIV = current Partial IV 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 Since the encrypting endpoint steps the Partial IV for each use, the
nonces used in case A are all unique as long as the number of nonces used in case A are all unique as long as the number of
encrypted messages is kept within the required range (Section 7.2.1). encrypted messages is kept within the required range (Section 7.2.1).
B. For responses without Partial IV (e.g. single response to a B. For responses without Partial IV (e.g., single response to a
request): request):
o ID_PIV = Sender ID of the endpoint generating the request o ID_PIV = Sender ID of the endpoint generating the request
o PIV = Partial IV of the request o PIV = Partial IV of the request
Since the Sender IDs are unique, ID_PIV is different from the Sender Since the Sender IDs are unique, ID_PIV is different from the Sender
ID of the encrypting endpoint. Therefore, the nonces in case B are ID of the encrypting endpoint. Therefore, the nonces in case B are
different compared to nonces in case A, where the encrypting endpoint different compared to nonces in case A, where the encrypting endpoint
generated the Partial IV. Since the Partial IV of the request is generated the Partial IV. Since the Partial IV of the request is
verified for replay (Section 7.4) associated to this Recipient verified for replay (Section 7.4) associated to this Recipient
Context, PIV is unique for this ID_PIV, which makes all nonces in Context, PIV is unique for this ID_PIV, which makes all nonces in
case B distinct. case B distinct.
D.5. Unprotected Message Fields D.5. Unprotected Message Fields
This sections analyses attacks on message fields which are not This section analyzes attacks on message fields that are not
protected by OSCORE according to the threat model Appendix D.1. protected by OSCORE according to the threat model Appendix D.1.
D.5.1. CoAP Header Fields D.5.1. CoAP Header Fields
o Version. The CoAP version [RFC7252] is not expected to be o Version. The CoAP version [RFC7252] is not expected to be
sensitive to disclose. Currently there is only one CoAP version sensitive to disclosure. Currently, there is only one CoAP
defined. A change of this parameter is potentially a denial-of- version defined. A change of this parameter is potentially a
service attack. Future versions of CoAP need to analyze attacks denial-of-service attack. Future versions of CoAP need to analyze
to OSCORE protected messages due to an adversary changing the CoAP attacks to OSCORE-protected messages due to an adversary changing
version. the CoAP version.
o Token/Token Length. The Token field is a client-local identifier o Token/Token Length. The Token field is a client-local identifier
for differentiating between concurrent requests [RFC7252]. CoAP for differentiating between concurrent requests [RFC7252]. CoAP
proxies are allowed to read and change Token and Token Length proxies are allowed to read and change Token and Token Length
between hops. An eavesdropper reading the Token can match between hops. An eavesdropper reading the Token can match
requests to responses which can be used in traffic analysis. In requests to responses that can be used in traffic analysis. In
particular this is true for notifications, where multiple particular, this is true for notifications, where multiple
responses are matched with one request. Modifications of Token responses are matched to one request. Modifications of Token and
and Token Length by an on-path attacker may become a denial-of- Token Length by an on-path attacker may become a denial-of-service
service attack, since it may prevent the client to identify to attack, since it may prevent the client to identify to which
which request the response belongs or to find the correct request the response belongs or to find the correct information to
information to verify integrity of the response. verify integrity of the response.
o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH
for requests with corresponding response codes. An endpoint for requests with corresponding response codes. An endpoint
receiving the message discards the Outer CoAP Code and uses the receiving the message discards the Outer CoAP Code and uses the
Inner CoAP Code instead (see Section 4.2). Hence, modifications Inner CoAP Code instead (see Section 4.2). Hence, modifications
from attackers to the Outer Code do not impact the receiving from attackers to the Outer Code do not impact the receiving
endpoint. However, changing the Outer Code from FETCH to a Code endpoint. However, changing the Outer Code from FETCH to a Code
value for a method that does not work with Observe (such as POST) value for a method that does not work with Observe (such as POST)
may, depending on proxy implementation since Observe is undefined may, depending on proxy implementation since Observe is undefined
for several Codes, cause the proxy to not forward notifications, for several Codes, cause the proxy to not forward notifications,
which is a denial-of-service attack. The use of FETCH rather than which is a denial-of-service attack. The use of FETCH rather than
POST reveals no more than what is revealed by the presence of the POST reveals no more than what is revealed by the presence of the
Outer Observe option. Outer Observe option.
o Type/Message ID. The Type/Message ID fields [RFC7252] reveal o Type/Message ID. The Type/Message ID fields [RFC7252] reveal
information about the UDP transport binding, e.g. an eavesdropper information about the UDP transport binding, e.g., an eavesdropper
reading the Type or Message ID gain information about how UDP reading the Type or Message ID gain information about how UDP
messages are related to each other. CoAP proxies are allowed to messages are related to each other. CoAP proxies are allowed to
change Type and Message ID. These message fields are not present change Type and Message ID. These message fields are not present
in CoAP over TCP [RFC8323], and does not impact the request/ in CoAP over TCP [RFC8323] and do not impact the request/response
response message. A change of these fields in a UDP hop is a message. A change of these fields in a UDP hop is a denial-of-
denial-of-service attack. By sending an ACK, an attacker can make service attack. By sending an ACK, an attacker can make the
the endpoint believe that it does not need to retransmit the endpoint believe that it does not need to retransmit the previous
previous message. By sending a RST, an attacker may be able to message. By sending a RST, an attacker may be able to cancel an
cancel an observation. By changing a NON to a CON, the attacker observation. By changing a NON to a CON, the attacker can cause
can cause the receiving endpoint to ACK messages for which no ACK the receiving endpoint to ACK messages for which no ACK was
was requested. requested.
o Length. This field contain the length of the message [RFC8323] o Length. This field contains the length of the message [RFC8323],
which may be used for traffic analysis. These message fields are which may be used for traffic analysis. This message field is not
not present in CoAP over UDP, and does not impact the request/ present in CoAP over UDP and does not impact the request/response
response message. A change of Length is a denial-of-service message. A change of Length is a denial-of-service attack similar
attack similar to changing TCP header fields. to changing TCP header fields.
D.5.2. CoAP Options D.5.2. CoAP Options
o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary
caching of OSCORE error responses. Changing this value thus may caching of OSCORE error responses. Changing this value thus may
cause unnecessary caching. No additional information is carried cause unnecessary caching. No additional information is carried
with this option. with this option.
o Proxy-Uri/Proxy-Scheme. These options are used in CoAP forward o Proxy-Uri/Proxy-Scheme. These options are used in CoAP forward
proxy deployments. With OSCORE, the Proxy-Uri option does not proxy deployments. With OSCORE, the Proxy-Uri option does not
contain the Uri-Path/Uri-Query parts of the URI. The other parts contain the Uri-Path/Uri-Query parts of the URI. The other parts
of Proxy-Uri cannot be protected because forward proxies need to of Proxy-Uri cannot be protected because forward proxies need to
change them in order to perform their functions. The server can change them in order to perform their functions. The server can
verify what scheme is used in the last hop, but not what was verify what scheme is used in the last hop, but not what was
requested by the client or what was used in previous hops. requested by the client or what was used in previous hops.
o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/
Uri-Port may be changed by an adversary, and the application needs Uri-Port may be changed by an adversary, and the application needs
to handle the consequences of that (see Section 4.1.3.2). The to handle the consequences of that (see Section 4.1.3.2). The
Uri-Host may either be omitted, reveal information equivalent to Uri-Host may either be omitted, reveal information equivalent to
that of the IP address or more privacy-sensitive information, that of the IP address, or reveal more privacy-sensitive
which is discouraged. information, which is discouraged.
o Observe. The Outer Observe option is intended for a proxy to o Observe. The Outer Observe option is intended for a proxy to
support forwarding of Observe messages, but is ignored by the support forwarding of Observe messages, but it is ignored by the
endpoints since the Inner Observe determines the processing in the endpoints since the Inner Observe option determines the processing
endpoints. Since the Partial IV provides absolute ordering of in the endpoints. Since the Partial IV provides absolute ordering
notifications it is not possible for an intermediary to spoof of notifications, it is not possible for an intermediary to spoof
reordering (see Section 4.1.3.5). The absence of Partial IV, reordering (see Section 4.1.3.5). The absence of Partial IV,
since only allowed for the first notification, does not prevent since only allowed for the first notification, does not prevent
correct ordering of notifications. The size and distributions of correct ordering of notifications. The size and distributions of
notifications over time may reveal information about the content notifications over time may reveal information about the content
or nature of the notifications. Cancellations (Section 4.1.3.5.1) or nature of the notifications. Cancellations (Section 4.1.3.5.1)
are not bound to the corresponding registrations in the same way are not bound to the corresponding registrations in the same way
responses are bound to requests in OSCORE (see Appendix D.3), but responses are bound to requests in OSCORE (see Appendix D.3).
that does not open up for attacks based on mismatched However, that does not make attacks based on mismatched
cancellations, since for cancellations to be accepted, all options cancellations possible, since for cancellations to be accepted,
in the decrypted message except for ETag Options MUST be the same all options in the decrypted message except for ETag options MUST
(see Section 4.1.3.5). be the same (see Section 4.1.3.5).
o Block1/Block2/Size1/Size2. The Outer Block options enables o Block1/Block2/Size1/Size2. The Outer Block options enable
fragmentation of OSCORE messages in addition to segmentation fragmentation of OSCORE messages in addition to segmentation
performed by the Inner Block options. The presence of these performed by the Inner Block options. The presence of these
options indicates a large message being sent and the message size options indicates a large message being sent, and the message size
can be estimated and used for traffic analysis. Manipulating can be estimated and used for traffic analysis. Manipulating
these options is a potential denial-of-service attack, e.g. these options is a potential denial-of-service attack, e.g.,
injection of alleged Block fragments. The specification of a injection of alleged Block fragments. The specification of a
maximum size of message, MAX_UNFRAGMENTED_SIZE maximum size of message, MAX_UNFRAGMENTED_SIZE
(Section 4.1.3.4.2), above which messages will be dropped, is (Section 4.1.3.4.2), above which messages will be dropped, is
intended as one measure to mitigate this kind of attack. intended as one measure to mitigate this kind of attack.
o No-Response. The Outer No-Response option is used to support o No-Response. The Outer No-Response option is used to support
proxy functionality, specifically to avoid error transmissions proxy functionality, specifically to avoid error transmissions
from proxies to clients, and to avoid bandwidth reduction to from proxies to clients, and to avoid bandwidth reduction to
servers by proxies applying congestion control when not receiving servers by proxies applying congestion control when not receiving
responses. Modifying or introducing this option is a potential responses. Modifying or introducing this option is a potential
denial-of-service attack against the proxy operations, but since denial-of-service attack against the proxy operations, but since
the option has an Inner value its use can be securely agreed the option has an Inner value, its use can be securely agreed upon
between the endpoints. The presence of this option is not between the endpoints. The presence of this option is not
expected to reveal any sensitive information about the message expected to reveal any sensitive information about the message
exchange. exchange.
o OSCORE. The OSCORE option contains information about the o OSCORE. The OSCORE option contains information about the
compressed COSE header. Changing this field may cause OSCORE compressed COSE header. Changing this field may cause OSCORE
verification to fail. verification to fail.
D.5.3. Error and Signaling Messages D.5.3. Error and Signaling Messages
Error messages occurring during CoAP processing are protected end-to- Error messages occurring during CoAP processing are protected end-to-
end. Error messages occurring during OSCORE processing are not end. Error messages occurring during OSCORE processing are not
always possible to protect, e.g. if the receiving endpoint cannot always possible to protect, e.g., if the receiving endpoint cannot
locate the right security context. For this setting, unprotected locate the right security context. For this setting, unprotected
error messages are allowed as specified to prevent extensive error messages are allowed as specified to prevent extensive
retransmissions. Those error messages can be spoofed or manipulated, retransmissions. Those error messages can be spoofed or manipulated,
which is a potential denial-of-service attack. which is a potential denial-of-service attack.
This document specifies OPTIONAL error codes and specific diagnostic This document specifies OPTIONAL error codes and specific diagnostic
payloads for OSCORE processing error messages. Such messages might payloads for OSCORE processing error messages. Such messages might
reveal information about how many and which security contexts exist reveal information about how many and which security contexts exist
on the server. Servers MAY want to omit the diagnostic payload of on the server. Servers MAY want to omit the diagnostic payload of
error messages, use the same error code for all errors, or avoid error messages, use the same error code for all errors, or avoid
skipping to change at page 89, line 25 skipping to change at page 93, line 19
restricted to transporting a protected CoAP message over an HTTP hop. restricted to transporting a protected CoAP message over an HTTP hop.
Any unprotected HTTP message fields may reveal information about the Any unprotected HTTP message fields may reveal information about the
transport of the OSCORE message and enable various denial-of-service transport of the OSCORE message and enable various denial-of-service
attacks. It is RECOMMENDED to additionally use TLS [RFC8446] for attacks. It is RECOMMENDED to additionally use TLS [RFC8446] for
HTTP hops, which enables encryption and integrity protection of HTTP hops, which enables encryption and integrity protection of
headers, but still leaves some information for traffic analysis. headers, but still leaves some information for traffic analysis.
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 [RFC8610]. This appendix
[I-D.ietf-cbor-cddl], which at the time of writing this appendix is summarizes the small subset of CDDL that is used in the present
in the process of completion. As the document is not yet available specification.
for a normative reference, the present appendix defines the small
subset of CDDL that is being used in the present specification.
Within the subset being used here, a CDDL rule is of the form "name = Within the subset being used here, a CDDL rule is of the form "name =
type", where "name" is the name given to the "type". A "type" can be type", where "name" is the name given to the "type". A "type" can be
one of: one of:
o a reference to another named type, by giving its name. The o a reference to another named type, by giving its name. The
predefined named types used in the present specification are: predefined named types used in the present specification are as
"uint", an unsigned integer (as represented in CBOR by major type follows: "uint", an unsigned integer (as represented in CBOR by
0); "int", an unsigned or negative integer (as represented in CBOR major type 0); "int", an unsigned or negative integer (as
by major type 0 or 1); "bstr", a byte string (as represented in represented in CBOR by major type 0 or 1); "bstr", a byte string
CBOR by major type 2); "tstr", a text string (as represented in (as represented in CBOR by major type 2); "tstr", a text string
CBOR by major type 3); (as represented in CBOR by major type 3);
o a choice between two types, by giving both types separated by a o a choice between two types, by giving both types separated by a
"/"; "/";
o an array type (as represented in CBOR by major type 4), where the o an array type (as represented in CBOR by major type 4), where the
sequence of elements of the array is described by giving a sequence of elements of the array is described by giving a
sequence of entries separated by commas ",", and this sequence is sequence of entries separated by commas ",", and this sequence is
enclosed by square brackets "[" and "]". Arrays described by an enclosed by square brackets "[" and "]". Arrays described by an
array description contain elements that correspond one-to-one to array description contain elements that correspond one-to-one to
the sequence of entries given. Each entry of an array description the sequence of entries given. Each entry of an array description
is of the form "name : type", where "name" is the name given to is of the form "name : type", where "name" is the name given to
the entry and "type" is the type of the array element the entry and "type" is the type of the array element
corresponding to this entry. corresponding to this entry.
Acknowledgments Acknowledgments
The following individuals provided input to this document: Christian The following individuals provided input to this document: Christian
Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Ben Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Ben
Campbell, Esko Dijk, Jaro Fietz, Thomas Fossati, Martin Gunnarsson, Campbell, Esko Dijk, Jaro Fietz, Thomas Fossati, Martin Gunnarsson,
Klaus Hartke, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Klaus Hartke, Rikard Hoeglund, Mirja Kuehlewind, Kathleen Moriarty,
Michael Richardson, Adam Roach, Jim Schaad, Peter van der Stok, Dave Eric Rescorla, Michael Richardson, Adam Roach, Jim Schaad, Peter van
Thaler, Martin Thomson, Marco Tiloca, William Vignat, and Malisa der Stok, Dave Thaler, Martin Thomson, Marco Tiloca, William Vignat,
Vucinic. and Malisa Vucinic.
Ludwig Seitz and Goeran Selander worked on this document as part of Ludwig Seitz and Goeran Selander worked on this document as part of
the CelticPlus project CyberWI, with funding from Vinnova. the CelticPlus project CyberWI, with funding from Vinnova. Ludwig
Seitz had additional funding from the SSF project SEC4Factory under
the grant RIT17-0032.
Authors' Addresses Authors' Addresses
Goeran Selander Goeran Selander
Ericsson AB Ericsson AB
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
John Mattsson John Mattsson
Ericsson AB Ericsson AB
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
Francesca Palombini Francesca Palombini
Ericsson AB Ericsson AB
Email: francesca.palombini@ericsson.com Email: francesca.palombini@ericsson.com
Ludwig Seitz Ludwig Seitz
RISE SICS RISE
Email: ludwig.seitz@ri.se Email: ludwig.seitz@ri.se
 End of changes. 408 change blocks. 
1045 lines changed or deleted 1060 lines changed or added

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