draft-ietf-core-object-security-14.txt   draft-ietf-core-object-security-15.txt 
CoRE Working Group G. Selander CoRE Working Group G. Selander
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: January 27, 2019 Ericsson AB Expires: March 4, 2019 Ericsson AB
L. Seitz L. Seitz
RISE SICS RISE SICS
July 26, 2018 August 31, 2018
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-14 draft-ietf-core-object-security-15
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 27, 2019. This Internet-Draft will expire on March 4, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 7 2. The OSCORE Option . . . . . . . . . . . . . . . . . . . . . . 7
3. The Security Context . . . . . . . . . . . . . . . . . . . . 7 3. The Security Context . . . . . . . . . . . . . . . . . . . . 7
3.1. Security Context Definition . . . . . . . . . . . . . . . 8 3.1. Security Context Definition . . . . . . . . . . . . . . . 8
3.2. Establishment of Security Context Parameters . . . . . . 10 3.2. Establishment of Security Context Parameters . . . . . . 10
3.3. Requirements on the Security Context Parameters . . . . . 12 3.3. Requirements on the Security Context Parameters . . . . . 13
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 13 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 14
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14 4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 15
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 22 4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 23
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 23 4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 24
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 23 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 25 5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 26
5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. AEAD Nonce . . . . . . . . . . . . . . . . . . . . . . . 26
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 27
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 27 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 28
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 28 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 29
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 28 6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 30
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 30 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 31
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 30 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 31
7. Message Binding, Sequence Numbers, Freshness and Replay 7. Message Binding, Sequence Numbers, Freshness and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 32 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 32 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 34
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 32 7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 34
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 33 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 34
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 35
7.5. Losing Part of the Context State . . . . . . . . . . . . 34 7.5. Losing Part of the Context State . . . . . . . . . . . . 36
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 36 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 37
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 36 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 38
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 38 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 39
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 39 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 40
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 40 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 42
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 41 10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 43
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 42 11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 44
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 42 11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 44
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 43 11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 45
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 44 11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 45
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 44 11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 46
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 44 11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 46
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 46 11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 48
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. Security Considerations . . . . . . . . . . . . . . . . . . . 49
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 47 12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 49
12.2. Security Context Establishment . . . . . . . . . . . . . 48 12.2. Security Context Establishment . . . . . . . . . . . . . 50
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 48 12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 50
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 49 12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 50
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 49 12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 51
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 49 12.6. Cryptographic Considerations . . . . . . . . . . . . . . 51
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 50 12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 51
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 50 12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 52
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 51 13.1. COSE Header Parameters Registry . . . . . . . . . . . . 53
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 51 13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 53
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 51 13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 54
13.4. Header Field Registrations . . . . . . . . . . . . . . . 52 13.4. Header Field Registrations . . . . . . . . . . . . . . . 55
13.5. Media Type Registrations . . . . . . . . . . . . . . . . 52 13.5. Media Type Registrations . . . . . . . . . . . . . . . . 55
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 54 13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 57
13.7. OSCORE Octet Registry . . . . . . . . . . . . . . . . . 54 13.7. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . 57
13.8. Expert Review Instructions . . . . . . . . . . . . . . . 55 13.8. Expert Review Instructions . . . . . . . . . . . . . . . 58
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . 59
14.2. Informative References . . . . . . . . . . . . . . . . . 57 14.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 59 Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 62
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 59 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 63
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 60 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 64
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 62 Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 65
B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 62 B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 65
B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 62 B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 65
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 63 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 66
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 63 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 67
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 65 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 68
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 66 C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 70
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 68 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 71
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 69 C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 73
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 70 C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 74
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 71 C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 75
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 72 C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 76
Appendix D. Overview of Security Properties . . . . . . . . . . 74 Appendix D. Overview of Security Properties . . . . . . . . . . 77
D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 74 D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 77
D.2. Protected Message Fields . . . . . . . . . . . . . . . . 74 D.2. Protected Message Fields . . . . . . . . . . . . . . . . 78
D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 75 D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 79
D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 76 D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 80
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 79 Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 83
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84
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], and may be mapped from HTTP [RFC8075]. CoAP specifies the
use of proxies for scalability and efficiency and references DTLS use of proxies for scalability and efficiency and references DTLS
[RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP
proxies require DTLS or TLS [RFC5246] 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 The proxy therefore 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 Observe CoAP features defined in [RFC7252], OSCORE supports the Observe
[RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and [RFC7641], Block-wise [RFC7959], and No-Response [RFC7967] options,
FETCH [RFC8132]. An analysis of end-to-end security for CoAP as well as the PATCH and FETCH methods [RFC8132]. An analysis of
messages through some types of intermediary nodes is performed in end-to-end security for CoAP messages through some types of
intermediary nodes is performed in
[I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the [I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the
RESTful interactions; the request method, the requested resource, the RESTful interactions; the request method, the requested resource, the
message payload, etc. (see Section 4). OSCORE protects neither the message payload, etc. (see Section 4). OSCORE protects neither the
CoAP Messaging Layer nor the CoAP Token which may change between the CoAP Messaging Layer nor the CoAP Token which may change between the
endpoints, and those are therefore processed as defined in [RFC7252]. endpoints, and those are therefore processed as defined in [RFC7252].
Additionally, since the message formats for CoAP over unreliable Additionally, since the message formats for CoAP over unreliable
transport [RFC7252] and for CoAP over reliable transport [RFC8323] transport [RFC7252] and for CoAP over reliable transport [RFC8323]
differ only in terms of CoAP Messaging Layer, OSCORE can be applied differ only in terms of CoAP Messaging Layer, OSCORE can be applied
to both unreliable and reliable transports (see Figure 1). to both unreliable and reliable transports (see Figure 1).
skipping to change at page 5, line 24 skipping to change at page 5, line 24
+-----------------------------------+ / +-----------------------------------+ /
+-----------------------------------+ +-----------------------------------+
| UDP / TCP / ... | | UDP / TCP / ... |
+-----------------------------------+ +-----------------------------------+
Figure 1: Abstract Layering of CoAP with OSCORE Figure 1: Abstract Layering of CoAP with OSCORE
OSCORE works in very constrained nodes and networks, thanks to its OSCORE works in very constrained nodes and networks, thanks to its
small message size and the restricted code and memory requirements in small message size and the restricted code and memory requirements in
addition to what is required by CoAP. Examples of the use of OSCORE addition to what is required by CoAP. Examples of the use of OSCORE
are given in Appendix A. OSCORE does not depend on underlying are given in Appendix A. OSCORE may be used over any underlying
layers, and can be used with non-IP transports (e.g., layer, such as e.g. UDP or TCP, and with non-IP transports (e.g.,
[I-D.bormann-6lo-coap-802-15-ie]). OSCORE may also be used in [I-D.bormann-6lo-coap-802-15-ie]). OSCORE may also be used in
different ways with HTTP. OSCORE messages may be transported in different ways with HTTP. OSCORE messages may be transported in
HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP
messages, as described below. messages, as described below.
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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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
following way: the original CoAP/HTTP message is translated to CoAP following way: the original CoAP/HTTP message is translated to CoAP
(if not already in CoAP) and protected in a COSE object. The (if not already in CoAP) and protected in a COSE object. The
encrypted message fields of this COSE object are transported in the encrypted message fields of this COSE object are transported in the
CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/ CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/
header field is included in the message. A sketch of an exchange of header field is included in the message. A sketch of an exchange of
OSCORE messages, in the case of the original message being CoAP, is OSCORE messages, in the case of the original message being CoAP, is
provided in Figure 2. provided in Figure 2. The use of OSCORE with HTTP is detailed in
Section 11.
Client Server Client Server
| OSCORE request - POST example.com: | | OSCORE request - POST example.com: |
| Header, Token, | | Header, Token, |
| Options: {OSCORE, ...}, | | Options: OSCORE, ..., |
| Payload: COSE ciphertext | | Payload: COSE ciphertext |
+--------------------------------------------->| +--------------------------------------------->|
| | | |
|<---------------------------------------------+ |<---------------------------------------------+
| OSCORE response - 2.04 (Changed): | | OSCORE response - 2.04 (Changed): |
| Header, Token, | | Header, Token, |
| Options: {OSCORE, ...}, | | Options: OSCORE, ..., |
| Payload: COSE ciphertext | | Payload: COSE ciphertext |
| | | |
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
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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/Sender/Recipient Context, Master Secret/Salt, Sender
ID/Key, Recipient ID/Key, ID Context, and Common IV are defined in ID/Key, Recipient ID/Key, ID Context, and Common IV are defined in
Section 3.1. Section 3.1.
2. The OSCORE Option 2. The OSCORE Option
The OSCORE option (see Figure 3, which extends Table 4 of [RFC7252]) The OSCORE option defined in this section (see Figure 3, which
indicates that the CoAP message is an OSCORE message and that it extends Table 4: Options of [RFC7252]) indicates that the CoAP
contains a compressed COSE object (see Sections 5 and 6). The OSCORE message is an OSCORE message and that it contains a compressed COSE
option is critical, safe to forward, part of the cache key, and not object (see Sections 5 and 6). The OSCORE option is critical, safe
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) | | TBD1 | 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
skipping to change at page 8, line 5 skipping to change at page 8, line 5
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 Additional Data (AEAD, [RFC5116])
algorithm for protecting message data between a client and a server. algorithm for protecting message data between a client and a server.
In this section, we define the security context and how it is derived In this section, we define the security context and how it is derived
in client and server based on a shared secret and a key derivation in client and server based on a shared secret and a key derivation
function (KDF). function.
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
skipping to change at page 8, line 29 skipping to change at page 9, line 5
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 and the other endpoint uses the same ID, now called Recipient ID
(RID), to derive its Recipient Context. In communication between two (RID), 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, | | Common, | | Common Context |
| Sender, | | Recipient, | +---------------------.----.---------------------+
| Recipient | | Sender | | Sender Context | = | Recipient 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
| | RID = kid | | RID = kid
| | Verify request with | | Verify request with
| | Recipient Context | | Recipient Context
| OSCORE response: | Protect response with | OSCORE response: | Protect response with
skipping to change at page 9, line 9 skipping to change at page 9, line 34
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 Key Derivation Function. The HMAC based HKDF [RFC5869] used to o An HMAC-based key derivation function HKDF [RFC5869] used to
derive Sender Key, Recipient Key, and Common IV. derive 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 traffic keys and IVs. 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 traffic keys and IVs. 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 traffic keys and IVs. derive AEAD keys and Common IV. The use of ID Context is
described in Section 5.1.
o Common IV. Byte string derived from Master Secret, Master Salt, o Common IV. Byte string derived from Master Secret, Master Salt,
and ID Context. Length is determined by the AEAD Algorithm. and ID Context. Used to generate the AEAD Nonce (see
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 traffic keys and IVs, and to assure unique nonces. Maximum derive AEAD keys and Common IV, and to assure unique AEAD nonces.
length is determined by the AEAD Algorithm. Maximum length is determined by the AEAD Algorithm.
o Sender Key. Byte string containing the symmetric key to protect o Sender Key. Byte string containing the symmetric AEAD key to
messages to send. Derived from Common Context and Sender ID. protect messages to send. Derived from Common Context and Sender
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 protect 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
nonces for the AEAD. Maximum value is determined by the AEAD AEAD nonces. Maximum value is determined by the AEAD Algorithm.
Algorithm. 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 traffic keys and IVs, and to assure unique nonces. to derive AEAD keys and Common IV, and to assure unique AEAD
Maximum length is determined by the AEAD Algorithm. nonces. Maximum length is determined by the AEAD Algorithm.
o Recipient Key. Byte string containing the symmetric key to verify o Recipient Key. Byte string containing the symmetric AEAD key to
messages received. Derived from Common Context and Recipient ID. verify messages received. Derived from Common Context and
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 to verify requests
received. received. Replay protection is described in Section 7.4 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
keys to be used. AEAD keys to be used.
3.2. Establishment of Security Context Parameters 3.2. Establishment of Security Context Parameters
The parameters in the security context are derived from a small set Each endpoint derives the parameters in the security context from a
of input parameters. The following input parameters SHALL be pre- small set of input parameters. The following input parameters SHALL
established: be pre-established:
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 pre-established. In case any
of these parameters is not pre-established, the default value of these parameters is not pre-established, the default value
indicated below is used: indicated 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 Key Derivation Function (KDF) o HMAC-based Key Derivation Function (HKDF)
* Default is HKDF SHA-256 * Default is HKDF SHA-256
o Replay Window Type and Size o Replay Window
* Default is DTLS-type replay protection with a window size of 32 * Default is DTLS-type replay protection with a window size of 32
[RFC6347] [RFC6347]
All input parameters need to be known to and agreed on by both All input parameters need to be known to and agreed on by both
endpoints, but the replay window may be different in the two endpoints, but the replay window may be different in the two
endpoints. The way the input parameters are pre-established, is endpoints. The way the input parameters are pre-established, 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 KDF 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
consists of the composition of the HKDF-Extract and HKDF-Expand steps consists of the composition of the HKDF-Extract and HKDF-Expand steps
[RFC5869]: [RFC5869]:
output parameter = HKDF(salt, IKM, info, L) output parameter = HKDF(salt, IKM, info, L)
where: where:
skipping to change at page 11, line 26 skipping to change at page 12, line 4
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
consists of the composition of the HKDF-Extract and HKDF-Expand steps consists of the composition of the HKDF-Extract and HKDF-Expand steps
[RFC5869]: [RFC5869]:
output parameter = HKDF(salt, IKM, info, L) output parameter = HKDF(salt, IKM, info, L)
where: where:
o salt is the Master Salt as defined above o salt is the Master Salt as defined above
o IKM is the Master Secret as defined above o IKM is the Master Secret as defined above
o info is the serialization of a CBOR array consisting of: o info is the serialization of a CBOR array consisting of (the
notation follows 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 keys and the o id is the Sender ID or Recipient ID when deriving Sender Key and
empty byte string when deriving the Common IV. The encoding is Recipient Key, respectively, and the empty byte string when
described in Section 5. 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/IV for the AEAD algorithm used, in bytes. o L is the size of the key/nonce for the AEAD algorithm used, in
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. 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
phase of HKDF produces a pseudorandom key (PRK) as follows:
PRK = HMAC-SHA-256(Master Salt, Master Secret)
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
Key, Recipient Key, and Common IV are therefore the first 16 or 13
bytes of
output parameter = HMAC-SHA-256(PRK, info | 0x01)
where different info are used for each derived parameter 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 in OSCORE sets the salt default value to empty byte string, which is
[RFC5869] is converted to a string of zeroes (see Section 2.2 of converted to a string of zeroes (see Section 2.2 of [RFC5869]).
[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 supported types The Sender Sequence Number is initialized to 0. The supported types
of replay protection and replay window length is application specific of replay protection and replay window length is application specific
and depends on how OSCORE is transported, see Section 7.4. The and depends on how OSCORE is transported, see Section 7.4. The
default is DTLS-type replay protection with a window size of 32 default is DTLS-type replay protection with a window size of 32
initiated as described in Section 4.1.2.6 of [RFC6347]. initiated as described in Section 4.1.2.6 of [RFC6347].
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, which avoids nonce requirement guarantees unique (key, nonce) pairs for the AEAD.
reuse.
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., [I-D.ietf-ace-oauth-authz]), or the identifiers
can be assigned out-of-band. The Sender IDs can be very short (note can be assigned out-of-band. The Sender IDs can be very short (note
that the empty string is a legitimate value). The maximum length of that the empty string is a legitimate value). The maximum length of
Sender ID in bytes equals the length of AEAD nonce minus 6. For AES- Sender ID in bytes equals the length of AEAD nonce minus 6, see
CCM-16-64-128 the maximum length of Sender ID is 7 bytes. Section 5.2. For AES-CCM-16-64-128 the maximum length of Sender ID
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
skipping to change at page 19, line 27 skipping to change at page 20, line 20
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
[I-D.hartke-core-e2e-security-reqs], i.e. that observations go [I-D.hartke-core-e2e-security-reqs], i.e. that observations go
through intermediary nodes, as illustrated in Figure 8 of [RFC7641]. through intermediary nodes, as illustrated in 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 in responses (with or The server SHALL include a new Partial IV (see Section 5) in
without the Observe option) to Observe registrations, except for the responses (with or without the Observe option) to Observe
first response where Partial IV MAY be omitted. registrations, except for the first response where Partial IV MAY be
omitted.
For cancellations, Section 3.6 of [RFC7641] specifies that all
options MUST be identical to those in the registration request except
for Observe and the set of ETag Options. For OSCORE 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 Observe is not defined, for messages with Observe,
the Outer Code MUST be set to 0.05 (FETCH) for requests and to 2.05 the Outer Code MUST be set to 0.05 (FETCH) for requests and to 2.05
(Content) for responses (see Section 4.2). (Content) for responses (see Section 4.2).
skipping to change at page 21, line 20 skipping to change at page 22, line 19
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 value to the three least
significant bytes of the Partial IV; such an implementation needs to significant bytes of the Partial IV. Implementations need to make
make sure that the Observe value for an observe notification without sure that the notification without Partial IV is considered the
Partial IV is smaller than a notification with Partial IV. 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
skipping to change at page 24, line 4 skipping to change at page 25, line 4
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 with an Authenticated Encryption with Additional Data
(AEAD) algorithm. The key lengths, IV length, nonce length, and (AEAD) algorithm. The AEAD key lengths, AEAD nonce length, and
maximum Sender Sequence Number are algorithm dependent. maximum Sender Sequence 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
nonce and Common IV is 13 bytes. The maximum Sender Sequence Number AEAD nonce and Common IV is 13 bytes. The maximum Sender Sequence
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.
skipping to change at page 25, line 34 skipping to change at page 26, line 34
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
| name | label | value type | value registry | description | | name | label | value type | value registry | description |
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
| kid | TBD2 | bstr | | Identifies the | | kid | TBD2 | bstr | | Identifies the |
| context | | | | context for kid | | context | | | | context for kid |
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
Figure 7: Common Header Parameter kid context for the COSE object Figure 7: Common Header Parameter kid context for the COSE object
5.2. Nonce 5.2. AEAD Nonce
The AEAD nonce is constructed in the following way (see Figure 8): The high level design of the AEAD nonce follows Section 4.4 of
[I-D.mcgrew-iv-gen], here follows the detailed construction (see
Figure 8):
1. left-padding the Partial IV (PIV) in network byte order with 1. left-pad the Partial IV (PIV) in network byte order with zeroes
zeroes to exactly 5 bytes, to exactly 5 bytes,
2. left-padding the Sender ID of the endpoint that generated the 2. left-pad the Sender ID of the endpoint that generated the Partial
Partial IV (ID_PIV) in network byte order with zeroes to exactly IV (ID_PIV) in network byte order with zeroes to exactly nonce
nonce length minus 6 bytes, length minus 6 bytes,
3. concatenating 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 XORing with the Common IV. 4. and then XOR with the Common IV.
Note that in this specification only algorithms that use nonces equal Note that in this specification only AEAD algorithms that use nonces
or greater than 7 bytes are supported. The nonce construction with equal or greater than 7 bytes are supported. The nonce construction
S, ID_PIV, and PIV together with endpoint unique IDs and encryption with S, ID_PIV, and PIV together with endpoint unique IDs and
keys makes it easy to verify that the nonces used with a specific key encryption keys makes it easy to verify that the nonces used with a
will be unique, see Appendix D.3. specific key will be unique, see Appendix D.3.
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. when
there is a single response to a request), the request and the 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.3. The only non-Observe properties, see Section 7.4 and Appendix D.3. The only non-Observe
scenario where a Partial IV must be included in a response is when scenario where a Partial IV must be included in a response is when
the server is unable to perform replay protection, see Section 7.5.2. the server is unable to perform replay protection, see Section 7.5.2.
For processing instructions see Section 8. For processing instructions see Section 8.
skipping to change at page 27, line 22 skipping to change at page 28, line 25
(only if there (only if there
is payload) is payload)
Figure 9: Plaintext Figure 9: Plaintext
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.
5.4. Additional Authenticated Data 5.4. Additional Authenticated Data
The external_aad SHALL be a CBOR array as defined below: The external_aad SHALL be a CBOR array wrapped in a bstr object as
defined below:
external_aad = [ external_aad = bstr .cbor 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
] ]
where: where:
o oscore_version: contains the OSCORE version number. o oscore_version: contains the OSCORE version number.
skipping to change at page 28, line 16 skipping to change at page 29, line 22
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 and are thus never 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 Additional Authenticated Data (AAD) is composed from the
external_add as described in Section 5.3 of [RFC8152]. external_aad as described in Section 5.3 of [RFC8152]:
AAD = Enc_structure = [ "Encrypt0", h'', external_aad ]
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
Class I options.
oscore_version = 0x01
algorithms = 0x810A
request_kid = 0x00
request_piv = 0x25
options = 0x
aad_array = 0x8501810A4100412540
external_aad = 0x498501810A4100412540
AAD = 0x8368456E63727970743040498501810A4100412540
Note that the AAD consists of a fixed string of 11 bytes concatenated
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. COSE is however constructed to support
a large number of different stateless use cases, and is not fully a large number of different stateless use cases, and is not fully
optimized for use as a stateful security protocol, leading to a optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion. In this section, we define larger than necessary message expansion. In this section, we define
skipping to change at page 29, line 17 skipping to change at page 30, line 33
|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, called OSCORE Octet, encodes the following set of o The first byte, containing the OSCORE flag bits, encodes the
flag 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 set * The fourth least significant bit is the kid flag, k: it is set
to 1 if the kid is present in the compressed COSE object. to 1 if the kid is present in the compressed COSE object.
* The fifth least significant bit is the kid context flag, h: it * The fifth least significant bit is the kid context flag, h: it
is set to 1 if the compressed COSE object contains a kid 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 3 of Section 8.2. decompression fails as specified in item 3 of Section 8.2.
The flag bits are registered in the OSCORE Octet registry specified The flag bits are registered in the OSCORE Flag Bits registry
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 encode the length of the kid context
(Section 5.1) s, if the kid context flag is set (h = 1). (Section 5.1) s, if the kid context flag is set (h = 1).
o The following s bytes encode the kid context, if the kid context o The following s bytes encode the kid context, if the kid context
flag is set (h = 1). flag is set (h = 1).
skipping to change at page 33, line 40 skipping to change at page 35, line 13
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 a
Partial IV received in the COSE object has not been received before. Partial IV = Sender Sequence Number received in the COSE object has
If this verification fails the server SHALL stop processing the not been received before. If this verification fails the server
message, and MAY optionally respond with a 4.01 Unauthorized error SHALL stop processing the message, and MAY optionally respond with a
message. Also, the server MAY set an Outer Max-Age option with value 4.01 Unauthorized error message. Also, the server MAY set an Outer
zero, to inform any intermediary that the response is not to be Max-Age option with value zero, to inform any intermediary that the
cached. The diagnostic payload MAY contain the "Replay detected" response is not to be cached. The diagnostic payload MAY contain the
string. The size and type of the Replay Window depends on the use "Replay detected" string. The size and type of the Replay Window
case and the protocol with which the OSCORE message is transported. depends on the use case and the protocol with which the OSCORE
In case of reliable and ordered transport from endpoint to endpoint, message is transported. In case of reliable and ordered transport
e.g. TCP, the server MAY just store the last received Partial IV and from endpoint to endpoint, e.g. TCP, the server MAY just store the
require that newly received Partial IVs equals the last received last received Partial IV and require that newly received Partial IVs
Partial IV + 1. However, in case of mixed reliable and unreliable equals the last received Partial IV + 1. However, in case of mixed
transports and where messages may be lost, such a replay mechanism reliable and unreliable transports and where messages may be lost,
may be too restrictive and the default replay window be more suitable such a replay mechanism may be too restrictive and the default replay
(see Section 3.2.2). window 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. Note that the Partial IV is not used for
replay protection in this case. replay protection in this case.
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
skipping to change at page 34, line 37 skipping to change at page 36, line 12
Applications MAY decide that a client only processes notifications Applications MAY decide that a client only processes notifications
which have greater Partial IV than the Notification Number. which have 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 key, or from To prevent reuse of an AEAD nonce with the same AEAD key, or from
accepting replayed messages, an endpoint needs to handle the accepting 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 request Token, Sender Sequence Number, Replay Window, and the request Token, Sender Sequence Number, Replay Window, and
Notification Numbers. These are typically stored in RAM and Notification Numbers. These are typically stored in RAM and
therefore lost in the case of an unplanned reboot. therefore lost in the case of an unplanned reboot.
After boot, an endpoint can either use a persistently stored complete After boot, an endpoint can either use a persistently stored complete
or partial security context, or establish a new security context with or partial security context, or establish a new security context with
each endpoint it communicates with. However, establishing a fresh each endpoint it communicates with. However, establishing a fresh
security context may have a non-negligible cost in terms of, e.g., security context may have a non-negligible cost in terms of, e.g.,
skipping to change at page 35, line 28 skipping to change at page 36, line 51
use of Sender Sequence Numbers. use of Sender Sequence Numbers.
7.5.2. Replay Window 7.5.2. Replay Window
To prevent accepting replay of previously received requests, the To prevent accepting replay of previously received requests, the
server may perform the following procedure after boot: server may perform the following procedure after boot:
o For each stored security context, the first time after boot the o For each stored security context, the first time after boot the
server receives an OSCORE request, the server responds with the server receives an OSCORE request, the server responds with the
Echo option [I-D.ietf-core-echo-request-tag] to get a request with Echo option [I-D.ietf-core-echo-request-tag] to get a request with
verifiable freshness. The server MUST use its Partial IV when verifiable freshness. The server MUST use its Sender Sequence
generating the AEAD nonce and MUST include the Partial IV in the Number (initiated as in Section 7.5.1) when generating the AEAD
response. nonce and MUST include it as Partial IV in the response.
If the server using the Echo option can verify a second request as If the server using the Echo option can verify a second request as
fresh, then the Partial IV of the second request is set as the lower fresh, then the Partial IV of the second request is set as the lower
limit of the replay window. limit of the replay window of Sender Sequence Numbers.
7.5.3. Replay of Notifications 7.5.3. Replay of Notifications
To prevent accepting replay of previously received notifications, the To prevent accepting replay of previously received notifications, the
client may perform the following procedure after boot: client may perform the following procedure after boot:
o The client forgets about earlier registrations, removes all o The client forgets about earlier registrations, removes all
Notification Numbers and registers using Observe. Notification Numbers and registers using Observe.
8. Processing 8. Processing
skipping to change at page 36, line 11 skipping to change at page 37, line 34
Note that, analogously to [RFC7252] where the Token and source/ Note that, analogously to [RFC7252] where the Token and source/
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
described in Section 3 of [I-D.mcgrew-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 Additional Authenticated Data and the plaintext, as
described in Sections 5.3 and 5.4. described in Sections 5.3 and 5.4.
skipping to change at page 37, line 15 skipping to change at page 38, line 42
value zero. The diagnostic payload SHOULD contain the string value zero. The diagnostic payload SHOULD 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 message. the server MAY respond with a 4.01 Unauthorized error message.
The server MAY set an Outer Max-Age option with value zero. The server MAY set an Outer Max-Age option with value zero.
The diagnostic payload SHOULD contain the string "Security The diagnostic payload SHOULD contain the string "Security
context not found". context not found".
3. Verify the 'Partial IV' parameter using the Replay Window, as 3. Verify that the 'Partial IV' has not been received before using
described in Section 7.4. the Replay Window, as described in Section 7.4.
4. Compose the Additional Authenticated Data, as described in 4. Compose the Additional Authenticated Data, 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' parameter, 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 [RFC8152]
Section 5.3. (The decrypt operation includes the verification of Section 5.3. (The decrypt operation includes the verification of
the integrity.) the integrity.)
skipping to change at page 38, line 23 skipping to change at page 39, line 50
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 Additional Authenticated Data and the plaintext, as
described in Sections 5.3 and 5.4. described in Sections 5.3 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 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.
skipping to change at page 38, line 50 skipping to change at page 40, line 29
If Observe is supported, insert the following step between step 2 and If Observe is supported, insert the following step between step 2 and
3 of Section 8.3: 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 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
skipping to change at page 39, line 37 skipping to change at page 41, line 19
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 Additional Authenticated Data, 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 nonce * If the Partial IV is not present in the response, the AEAD
from the request is used. nonce from the request is used.
* If the Partial IV is present in the response, compute the * 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. parameter, 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 [RFC8152]
Section 5.3. (The decrypt operation includes the verification of Section 5.3. (The decrypt operation includes the verification of
the integrity.) If decryption fails, then go to 8. 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.
skipping to change at page 40, line 26 skipping to change at page 42, line 8
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 Inner
Observe is present, and the nonce from the request was already Observe is present, and the AEAD nonce from the request was
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 Inner Observe is
present, then follow the processing described in Section 4.1.3.5.2 present, then follow the processing described in Section 4.1.3.5.2
and Section 7.4.1, then: 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).
skipping to change at page 48, line 24 skipping to change at page 50, line 16
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 pre-established or obtained using a key
establishment protocol augmented with establishment of Sender/ establishment protocol augmented with establishment of Sender/
Recipient ID such as the OSCORE profile of the ACE framework Recipient ID such as the OSCORE profile of the ACE framework
[I-D.ietf-ace-oscore-profile]. Such a procedure must ensure that the [I-D.ietf-ace-oscore-profile]. Such a procedure must ensure that the
requirements of the security context parameters for the intended use requirements of the security context parameters for the intended use
are complied with (see Section 3.3) and also in error situations. It are complied with (see Section 3.3) and also in error situations.
is recommended to use a key establishment protocol which provides While recipient IDs are allowed to coincide between different
forward secrecy whenever possible. Considerations for deploying security contexts (see Section 3.3), this may cause a server to
OSCORE with a fixed Master Secret are given in Appendix B. process multiple verifications before finding the right security
context or rejecting a message. Moreover, it is recommended to use a
key establishment protocol which provides forward secrecy whenever
possible. 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. HKDF denotes in this specification 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 Key Material (IKM).
skipping to change at page 48, line 49 skipping to change at page 50, line 45
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 is has 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 [I-D.ietf-ace-oscore-profile], the Master Secret can be generated
offline using a good random number generator. offline using a good random number generator. Randomness
requirements for security 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 number which are
skipping to change at page 49, line 37 skipping to change at page 51, line 31
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 [I-D.ietf-core-echo-request-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 nonce (Section 5.2) must be generated. The mechanism to build the AEAD nonce
assumes that the nonce is at least 56 bits, and the Partial IV is at (Section 5.2) assumes that the nonce is at least 56 bits, and the
most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM- Partial IV is at most 40 bits. The mandatory-to-implement AEAD
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.
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 keys, the repeatedly encrypted by many different users with distinct AEAD keys,
nonce is formed by mixing the sequence number with a secret per- the AEAD nonce is formed by mixing the sequence number with a secret
context initialization vector (Common IV) derived along with the keys per-context initialization vector (Common IV) derived along with the
(see Section 3.1 of [RFC8152]), and by using a Master Salt in the key keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in
derivation (see [MF00] for an overview). The Master Secret, Sender the key derivation (see [MF00] for an overview). The Master Secret,
Key, Recipient Key, and Common IV must be secret, the rest of the Sender Key, Recipient Key, and Common IV must be secret, the rest of
parameters may be public. The Master Secret must have a good amount the parameters may be public. The Master Secret must have a good
of randomness (see Section 12.3). amount of randomness (see Section 12.3).
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 can by policy be restricted
in size since the Inner Block options allow for secure fragmentation in size since the Inner Block options allow for secure fragmentation
of very large messages. A maximum message size (above which the of very large messages. A maximum message size (above which the
skipping to change at page 51, line 47 skipping to change at page 53, line 43
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 is added to the CoAP Option Numbers registry:
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| Number | Name | Reference | | Number | Name | Reference |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
| TBD1 | OSCORE | [[this document]] | | TBD1 | OSCORE | [[this document]] |
+--------+-----------------+-------------------+ +--------+-----------------+-------------------+
Note to IANA: Label assignment in (Integer value between 0 and 12) is
requested. We also request Expert review if possible, to make sure a
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:
+--------+-----------------+---------------------------------------+
| Number | Name | Reference |
+--------+-----------------+---------------------------------------+
| 1 | If-Match | [RFC7252] [[this document]] |
| 3 | Uri-Host | [RFC7252] [[this document]] |
| 4 | ETag | [RFC7252] [[this document]] |
| 5 | If-None-Match | [RFC7252] [[this document]] |
| 6 | Observe | [RFC7641] [[this document]] |
| 7 | Uri-Port | [RFC7252] [[this document]] |
| 8 | Location-Path | [RFC7252] [[this document]] |
| 11 | Uri-Path | [RFC7252] [[this document]] |
| 12 | Content-Format | [RFC7252] [[this document]] |
| 14 | Max-Age | [RFC7252] [[this document]] |
| 15 | Uri-Query | [RFC7252] [[this document]] |
| 17 | Accept | [RFC7252] [[this document]] |
| 20 | Location-Query | [RFC7252] [[this document]] |
| 23 | Block2 | [RFC7959] [RFC8323] [[this document]] |
| 27 | Block1 | [RFC7959] [RFC8323] [[this document]] |
| 28 | Size2 | [RFC7959] [[this document]] |
| 35 | Proxy-Uri | [RFC7252] [[this document]] |
| 39 | Proxy-Scheme | [RFC7252] [[this document]] |
| 60 | Size1 | [RFC7252] [[this document]] |
| 258 | No-Response | [RFC7967] [[this document]] |
+--------+-----------------+---------------------------------------+
Future additions to the CoAP Option Numbers registry need to provide
a reference to the document where the OSCORE processing of 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 is added to the CoAP Signaling Option Numbers
registry: registry:
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| 7.xx (any) | TBD1 | OSCORE | [[this document]] | | 7.xx (all) | TBD1 | OSCORE | [[this document]] |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
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 is 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 | [[this document]], Section 11.1 |
+----------------------+----------+----------+-------------------+ +-------------------+----------+----------+---------------------------------+
13.5. Media Type Registrations 13.5. Media Type Registrations
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. These media types are used to indicate that
the content is an OSCORE message. The OSCORE body cannot be the content is an OSCORE message. The OSCORE body cannot be
understood without the OSCORE header field value and the security understood without the OSCORE header field value and the security
context. context.
Type name: application Type name: application
skipping to change at page 54, line 11 skipping to change at page 57, line 11
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. Note to IANA: ID assignment in the 10000-64999 range is requested.
(RFC Editor: Delete this note after IANA assignment) (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-Format" 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 | | TBD3 | [[this document]] |
+----------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
13.7. OSCORE Octet Registry 13.7. OSCORE Flag Bits Registry
It is requested that IANA create a new registry entitled "OSCORE This document defines a sub-registry for the OSCORE flag bits within
Octet". The registry should be created with the Expert Review the "CoRE Parameters" registry. The name of the sub-registry is
policy. Guidelines for the experts are provided in Section 13.8. "OSCORE Flag Bits". The registry should be created with the Expert
Review policy. Guidelines for the experts are provided in
Section 13.8.
The columns of the registry are: The columns of the registry are:
o bit position: This indicates the position of the bit in the OSCORE o bit position: This indicates the position of the bit in the set of
Octet, starting at 0 for the most significant bit. The bit OSCORE flag bits, starting at 0 for the most significant bit. The
position must be an integer or a range of integers, in the range 0 bit position must be an integer or a range of integers, in the
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 specification: This contains a pointer to the specification
defining the entry. defining the entry.
The initial contents of the registry can be found in Figure 12. The The initial contents of the registry can be found in the table below.
specification column for all rows in that table should be this The specification column for all rows in that table should be this
document. Additionally, the entry with Bit Position of 0 is to be document. The entries with Bit Position of 0 and 1 are to be marked
marked as 'Reserved'. This entry is going to be specified in a as 'Reserved'. The entry with Bit Position of 1 is going to be
future document, and will be used to expand the OSCORE Octet in specified in a future document, and will be used to expand the space
Section 6.1, so that entries 8-63 of the registry are defined. for the OSCORE flag bits in Section 6.1, so that entries 8-63 of the
registry are defined.
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| Bit Position | Name | Description | Specification | | Bit Position | Name | Description | Specification |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| 0 | Reserved | | | | 0 | Reserved | | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| 1 | Reserved | | |
+--------------+-------------+---------------------+-------------------+
| 2 | Unassigned | | |
+--------------+-------------+---------------------+-------------------+
| 3 | Kid Context | Set to 1 if kid | [[this document]] | | 3 | Kid Context | Set to 1 if kid | [[this document]] |
| | Flag | context is present | | | | Flag | context is present | |
| | | in the compressed | | | | | in the compressed | |
| | | COSE object | | | | | COSE object | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| 4 | Kid Flag | Set to 1 if kid is | [[this document]] | | 4 | Kid Flag | Set to 1 if kid is | [[this document]] |
| | | present in the com- | | | | | present in the com- | |
| | | pressed COSE object | | | | | pressed COSE object | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| 5-7 | Partial IV | Encodes the Partial | [[this document]] | | 5-7 | Partial IV | Encodes the Partial | [[this document]] |
| | Length | IV length; can have | | | | Length | IV length; can have | |
| | | value 0 to 5 | | | | | value 0 to 5 | |
+--------------+-------------+---------------------+-------------------+ +--------------+-------------+---------------------+-------------------+
| 8-63 | Unassigned | | |
Figure 12 +--------------+-------------+---------------------+-------------------+
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
hardly be solved 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 Octet points are defined (i.e. until the mechanism for the OSCORE flag bits
expansion via bit 0 is specified). 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>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
skipping to change at page 57, line 34 skipping to change at page 60, line 44
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018, RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
14.2. Informative References 14.2. Informative References
[I-D.bormann-6lo-coap-802-15-ie] [I-D.bormann-6lo-coap-802-15-ie]
Bormann, C., "Constrained Application Protocol (CoAP) over Bormann, C., "Constrained Application Protocol (CoAP) over
IEEE 802.15.4 Information Element for IETF", draft- IEEE 802.15.4 Information Element for IETF", draft-
bormann-6lo-coap-802-15-ie-00 (work in progress), April bormann-6lo-coap-802-15-ie-00 (work in progress), April
2016. 2016.
[I-D.hartke-core-e2e-security-reqs] [I-D.hartke-core-e2e-security-reqs]
Selander, G., Palombini, F., and K. Hartke, "Requirements Selander, G., Palombini, F., and K. Hartke, "Requirements
skipping to change at page 58, line 14 skipping to change at page 61, line 32
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander, Seitz, L., Palombini, F., Gunnarsson, M., and G. Selander,
"OSCORE profile of the Authentication and Authorization "OSCORE profile of the Authentication and Authorization
for Constrained Environments Framework", draft-ietf-ace- for Constrained Environments Framework", draft-ietf-ace-
oscore-profile-02 (work in progress), June 2018. oscore-profile-02 (work in progress), June 2018.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-03 express CBOR and JSON data structures", draft-ietf-cbor-
(work in progress), July 2018. cddl-05 (work in progress), August 2018.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "Echo and Amsuess, C., Mattsson, J., and G. Selander, "Echo and
Request-Tag", draft-ietf-core-echo-request-tag-02 (work in Request-Tag", draft-ietf-core-echo-request-tag-02 (work in
progress), June 2018. progress), June 2018.
[I-D.ietf-core-oscore-groupcomm] [I-D.ietf-core-oscore-groupcomm]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Secure group communication for CoAP", draft-ietf-core- "Secure group communication for CoAP", draft-ietf-core-
oscore-groupcomm-02 (work in progress), June 2018. oscore-groupcomm-02 (work in progress), June 2018.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-05 (work in progress), March mattsson-core-coap-actuators-05 (work in progress), March
2018. 2018.
[I-D.mcgrew-iv-gen]
McGrew, D., "Generation of Deterministic Initialization
Vectors (IVs) and Nonces", draft-mcgrew-iv-gen-03 (work in
progress), October 2013.
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of [MF00] McGrew, D. and S. Fluhrer, "Attacks on Encryption of
Redundant Plaintext and Implications on Internet Redundant Plaintext and Implications on Internet
Security", the Proceedings of the Seventh Annual Workshop Security", the Proceedings of the Seventh Annual Workshop
on Selected Areas in Cryptography (SAC 2000), Springer- on Selected Areas in Cryptography (SAC 2000), Springer-
Verlag. , 2000. Verlag. , 2000.
[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 60, line 30 skipping to change at page 63, line 38
| | 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 13: Secure Access to Sensor. Square brackets [ ... ] indicate Figure 12: Secure Access to Sensor. Square brackets [ ... ] indicate
content of compressed COSE object. Curly brackets { ... } indicate content of compressed COSE object. Curly brackets { ... } indicate
encrypted data. encrypted data.
The request/response Codes are encrypted by OSCORE and only dummy The request/response Codes are encrypted by OSCORE and only dummy
Codes (POST/Changed) are visible in the header of the OSCORE message. Codes (POST/Changed) are visible in the header of the OSCORE message.
The option Uri-Path ("alarm_status") and payload ("0") are encrypted. 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).
skipping to change at page 61, line 48 skipping to change at page 65, line 8
| | | 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,
| | | Content-Format:0, "180"} | | | Content-Format:0, "180"}
| | | | | |
Figure 14: Secure Subscribe to Sensor. Square brackets [ ... ] Figure 13: Secure Subscribe to Sensor. Square brackets [ ... ]
indicate content of compressed COSE object header. Curly brackets { indicate content of compressed COSE object header. Curly brackets {
... } indicate encrypted data. ... } indicate encrypted data.
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 headers of the responses contains Partial
skipping to change at page 62, line 36 skipping to change at page 65, line 43
An application may derive a security context once and use it for the An application may derive a security context once and use it for the
lifetime of a device. For many IoT deployments, a 128 bit uniformly lifetime of a device. For many IoT deployments, a 128 bit uniformly
random Master Key is sufficient for encrypting all data exchanged random Master Key is sufficient for encrypting all data exchanged
with the IoT device. This specification describes techniques for with the IoT device. This specification describes techniques for
persistent storage of the security context and synchronization of persistent storage of the security context and synchronization of
sequence numbers (see Section 7.5) to ensure that security is sequence numbers (see Section 7.5) to ensure that security is
maintained with the existing security context. maintained with the existing security context.
B.2. Master Secret Used Multiple Times B.2. Master Secret Used Multiple Times
Section 12.2 recommends the use of a key establishment protocol Section 12.2 recommends that the Master Secret is obtained from a key
providing forward secrecy of the Master Secret. establishment protocol providing forward secrecy.
An application which does not require forward secrecy may allow An application which 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 an application allowing new security This section gives an example of an application allowing new security
contexts to be derived from input parameters pre-established between contexts to be derived from input parameters pre-established between
client and server for this purpose: in particular Master Secret, client and server for this purpose: in particular Master Secret,
skipping to change at page 63, line 37 skipping to change at page 66, line 46
The procedures may be complemented with the use of the Echo option The procedures may be complemented with the use of the Echo option
for verifying the aliveness of the client requesting a new security for verifying the aliveness of the client requesting a new security
context. context.
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
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
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 KDF. 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)
o Master Salt: 0x9e7ca92223786340 (8 bytes) o Master Salt: 0x9e7ca92223786340 (8 bytes)
o Sender ID: 0x (0 byte) o Sender ID: 0x (0 byte)
skipping to change at page 64, line 25 skipping to change at page 67, line 43
o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes) o Sender Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Recipient Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) o Common IV: 0x4622d4dd6d944168eefb54987c (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: 0x4622d4dd6d944168eefb54987c o sender nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
o recipient nonce: 0x4722d4dd6d944169eefb54987c o recipient nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
C.1.2. Server C.1.2. Server
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)
o Sender ID: 0x01 (1 byte) o Sender ID: 0x01 (1 byte)
o Recipient ID: 0x (0 byte) o Recipient ID: 0x (0 byte)
From the previous parameters, From the previous parameters,
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes) o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
skipping to change at page 65, line 4 skipping to change at page 68, line 21
o info (for Sender Key): 0x854101f60a634b657910 (10 bytes) o info (for Sender Key): 0x854101f60a634b657910 (10 bytes)
o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes) o info (for Recipient Key): 0x8540f60a634b657910 (9 bytes)
o info (for Common IV): 0x8540f60a6249560d (8 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs: Outputs:
o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes) o Sender Key: 0xffb14e093c94c9cac9471648b4f98710 (16 bytes)
o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes) o Recipient Key: 0xf0910ed7295e6ad4b54fc793154302ff (16 bytes)
o Common IV: 0x4622d4dd6d944168eefb54987c (13 bytes) o Common IV: 0x4622d4dd6d944168eefb54987c (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: 0x4722d4dd6d944169eefb54987c o sender nonce: 0x4722d4dd6d944169eefb54987c (13 bytes)
o recipient nonce: 0x4622d4dd6d944168eefb54987c o recipient nonce: 0x4622d4dd6d944168eefb54987c (13 bytes)
C.2. Test Vector 2: Key Derivation without Master Salt C.2. Test Vector 2: Key Derivation without Master Salt
In this test vector, the default values are used for AEAD Algorithm, In this test vector, the default values are used for AEAD Algorithm,
KDF, and Master Salt. HKDF, and Master Salt.
C.2.1. Client C.2.1. Client
Inputs: Inputs:
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Sender ID: 0x00 (1 byte) o Sender ID: 0x00 (1 byte)
o Recipient ID: 0x01 (1 byte) o Recipient ID: 0x01 (1 byte)
skipping to change at page 65, line 49 skipping to change at page 69, line 19
o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes) o Sender Key: 0x321b26943253c7ffb6003b0b64d74041 (16 bytes)
o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (16 bytes) o Recipient Key: 0xe57b5635815177cd679ab4bcec9d7dda (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: 0xbf35ae297d2dace910c52e99f9 o sender nonce: 0xbf35ae297d2dace910c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace810c52e99f9 o recipient nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
C.2.2. Server C.2.2. Server
Inputs: Inputs:
o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes) o Master Secret: 0x0102030405060708090a0b0c0d0e0f10 (16 bytes)
o Sender ID: 0x01 (1 byte) o Sender ID: 0x01 (1 byte)
o Recipient ID: 0x00 (1 byte) o Recipient ID: 0x00 (1 byte)
skipping to change at page 66, line 34 skipping to change at page 70, line 5
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 o sender nonce: 0xbf35ae297d2dace810c52e99f9 (13 bytes)
o recipient nonce: 0xbf35ae297d2dace910c52e99f9 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 a 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
KDF. 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)
o Sender ID: 0x (0 byte) o Sender ID: 0x (0 byte)
skipping to change at page 67, line 30 skipping to change at page 70, line 51
o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes) o Sender Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes) o Recipient Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes) o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (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: 0x2ca58fb85ff1b81c0b7181b85e o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes)
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o recipient nonce: 0x2da58fb85ff1b81d0b7181b85e
C.3.2. Server C.3.2. Server
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)
o Sender ID: 0x01 (1 byte) o Sender ID: 0x01 (1 byte)
skipping to change at page 68, line 22 skipping to change at page 71, line 42
o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes) o Sender Key: 0xe39a0c7c77b43f03b4b39ab9a268699f (16 bytes)
o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes) o Recipient Key: 0xaf2a1300a5e95788b356336eeecd2b92 (16 bytes)
o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (13 bytes) o Common IV: 0x2ca58fb85ff1b81c0b7181b85e (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: 0x2da58fb85ff1b81d0b7181b85e o sender nonce: 0x2da58fb85ff1b81d0b7181b85e (13 bytes)
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e 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)
skipping to change at page 70, line 36 skipping to change at page 74, line 11
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 carrying the ID Context in the message, using the security request for an application that sets the ID Context and requires it
context derived in Appendix C.3. The unprotected request only to be sent in the request, so kid context is present in the protected
contains the Uri-Path and Uri-Host options. message. This test vector uses the security context derived in
Appendix C.3. The unprotected request only contains the Uri-Path and
Uri-Host options.
Unprotected CoAP request: Unprotected CoAP request:
0x44012f8eef9bbf7a396c6f63616c686f737483747631 (22 bytes) 0x44012f8eef9bbf7a396c6f63616c686f737483747631 (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
skipping to change at page 71, line 38 skipping to change at page 75, line 14
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): 0x44022f8eef9bbf7a396c6f6 o Protected CoAP request (OSCORE message):
3616c686f73746b19140837cbf3210017a2d3ff4ed339a5a379b0b8bc731fffb0 0x44022f8eef9bbf7a396c6f63616c686f73746b19140837cbf3210017a2d3ff
(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:
skipping to change at page 74, line 20 skipping to change at page 77, line 41
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 transport layer protects the entire message between
the endpoints in which case CoAP proxy operations are not possible. the endpoints in which case CoAP proxy operations are not possible.
In order to enable proxy operations, security on transport layer In order to enable proxy operations, security on transport layer
needs to be terminated at the proxy in which case the CoAP message in needs to be terminated at the proxy in which case the CoAP message in
its entirety is unprotected in the proxy. 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]. The client and server are [I-D.hartke-core-e2e-security-reqs], in particular forwarding is
assumed to be honest, but proxies and gateways are only trusted to detailed in Section 2.2.1. The client and server are assumed to be
perform their intended operations. Forwarding is specified in honest, while proxies and gateways are only trusted to perform their
Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs]. HTTP-CoAP intended operations.
translation is specified in [RFC8075]. Intermediaries translating
between different transport layers are intended to perform just that.
By working at the CoAP layer, OSCORE enables different CoAP message 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.2. Protected Message Fields D.2. Protected Message Fields
skipping to change at page 76, line 46 skipping to change at page 80, line 20
D.4.1. CoAP Header Fields D.4.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 disclose. Currently there is only one CoAP version
defined. A change of this parameter is potentially a denial-of- defined. A change of this parameter is potentially a denial-of-
service attack. Future versions of CoAP need to analyze attacks service attack. Future versions of CoAP need to analyze attacks
to OSCORE protected messages due to an adversary changing the CoAP to OSCORE protected messages due to an adversary changing the CoAP
version. 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]. An for differentiating between concurrent requests [RFC7252]. CoAP
eavesdropper reading the token can match requests to responses proxies are allowed to read and change Token and Token Length
which can be used in traffic analysis. In particular this is true between hops. An eavesdropper reading the Token can match
for notifications, where multiple responses are matched with one requests to responses which can be used in traffic analysis. In
request. CoAP proxies are allowed to change Token and Token particular this is true for notifications, where multiple
Length between UDP hops. However, modifications of Token and responses are matched with one request. Modifications of Token
Token Length during a UDP hop may become a denial-of-service and Token Length by an on-path attacker may become a denial-of-
attack, since it may prevent the client to identify to which service attack, since it may prevent the client to identify to
request the response belongs or to find the correct information to which request the response belongs or to find the correct
verify integrity of the response. information to 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. The use of FETCH for requests with corresponding response codes. The use of FETCH
reveals no more than what is revealed by the Outer Observe option. reveals no more than what is revealed by the Outer Observe option.
Changing the Outer Code may be a denial-of-service attack by Changing the Outer Code may be a denial-of-service attack by
causing errors in the proxy processing. causing errors in the proxy processing.
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
skipping to change at page 78, line 25 skipping to change at page 81, line 46
endpoints. Since the Partial IV provides absolute ordering of endpoints. Since the Partial IV provides absolute ordering of
notifications it is not possible for an intermediary to spoof 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.2), but responses are bound to requests in OSCORE (see Appendix D.2), but
that does not open up for attacks based on mismatched that does not open up for attacks based on mismatched
cancellations, since [RFC7641] specifies that for cancellations to cancellations, since for cancellations to be accepted, all options
be accepted, all options except for ETags MUST be the same (see in the decrypted message except for ETag Options MUST be the same
Section 3.6 of [RFC7641]). For different target resources, the (see Section 4.1.3.5).
OSCORE option is different, and even if the Token is modified to
match a different observation, such a cancellation would not be
accepted.
o Block1/Block2/Size1/Size2. The Outer Block options enables o Block1/Block2/Size1/Size2. The Outer Block options enables
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
skipping to change at page 79, line 30 skipping to change at page 82, line 48
hop-by-hop; spoofing signaling messages can be used as a denial-of- hop-by-hop; spoofing signaling messages can be used as a denial-of-
service attack of a TCP connection. service attack of a TCP connection.
D.4.4. HTTP Message Fields D.4.4. HTTP Message Fields
In contrast to CoAP, where OSCORE does not protect header fields to In contrast to CoAP, where OSCORE does not protect header fields to
enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is
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 [RFC5246] 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. CDDL is defined in
[I-D.ietf-cbor-cddl], which at the time of writing this appendix is [I-D.ietf-cbor-cddl], which at the time of writing this appendix is
in the process of completion. As the document is not yet available in the process of completion. As the document is not yet available
for a normative reference, the present appendix defines the small for a normative reference, the present appendix defines the small
 End of changes. 115 change blocks. 
303 lines changed or deleted 432 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/