draft-ietf-core-object-security-13.txt   draft-ietf-core-object-security-14.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: December 29, 2018 Ericsson AB Expires: January 27, 2019 Ericsson AB
L. Seitz L. Seitz
RISE SICS RISE SICS
June 27, 2018 July 26, 2018
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-13 draft-ietf-core-object-security-14
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 December 29, 2018. This Internet-Draft will expire on January 27, 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 22 skipping to change at page 2, line 22
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 . . . . . 12
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 13 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 13
4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14 4.1. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14
4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 21 4.2. CoAP Header Fields and Payload . . . . . . . . . . . . . 22
4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 23 4.3. Signaling Messages . . . . . . . . . . . . . . . . . . . 23
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 23 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 26
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 27 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 27
6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 28 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 28
6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 28 6.1. Encoding of the OSCORE Option Value . . . . . . . . . . . 28
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 30 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 30
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 30 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 30
7. Message Binding, Sequence Numbers, Freshness and Replay 7. Message Binding, Sequence Numbers, Freshness and Replay
Protection . . . . . . . . . . . . . . . . . . . . . . . . . 32 Protection . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 32 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 32
7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 32 7.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 32
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 33 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 33
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33
7.5. Losing Part of the Context State . . . . . . . . . . . . 34 7.5. Losing Part of the Context State . . . . . . . . . . . . 34
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 35 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 36 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 36
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 36 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 36
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 37 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 38
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 38 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 39
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 40 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 40
10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 41 10. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . . . . 41
11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 42 11. HTTP Operations . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 42 11.1. The HTTP OSCORE Header Field . . . . . . . . . . . . . . 42
11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 43 11.2. CoAP-to-HTTP Mapping . . . . . . . . . . . . . . . . . . 43
11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 43 11.3. HTTP-to-CoAP Mapping . . . . . . . . . . . . . . . . . . 44
11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 44 11.4. HTTP Endpoints . . . . . . . . . . . . . . . . . . . . . 44
11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 44 11.5. Example: HTTP Client and CoAP Server . . . . . . . . . . 44
11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 46 11.6. Example: CoAP Client and HTTP Server . . . . . . . . . . 46
12. Security Considerations . . . . . . . . . . . . . . . . . . . 47 12. Security Considerations . . . . . . . . . . . . . . . . . . . 47
12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 47 12.1. End-to-end Protection . . . . . . . . . . . . . . . . . 47
12.2. Security Context Establishment . . . . . . . . . . . . . 48 12.2. Security Context Establishment . . . . . . . . . . . . . 48
12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 48 12.3. Master Secret . . . . . . . . . . . . . . . . . . . . . 48
12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 48 12.4. Replay Protection . . . . . . . . . . . . . . . . . . . 49
12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 49 12.5. Client Aliveness . . . . . . . . . . . . . . . . . . . . 49
12.6. Cryptographic Considerations . . . . . . . . . . . . . . 49 12.6. Cryptographic Considerations . . . . . . . . . . . . . . 49
12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 49 12.7. Message Segmentation . . . . . . . . . . . . . . . . . . 50
12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 50 12.8. Privacy Considerations . . . . . . . . . . . . . . . . . 50
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
13.1. COSE Header Parameters Registry . . . . . . . . . . . . 51 13.1. COSE Header Parameters Registry . . . . . . . . . . . . 51
13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 51 13.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 51
13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 51 13.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 51
13.4. Header Field Registrations . . . . . . . . . . . . . . . 51 13.4. Header Field Registrations . . . . . . . . . . . . . . . 52
13.5. Media Type Registrations . . . . . . . . . . . . . . . . 52 13.5. Media Type Registrations . . . . . . . . . . . . . . . . 52
13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 54 13.6. CoAP Content-Formats Registry . . . . . . . . . . . . . 54
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.7. OSCORE Octet Registry . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . 54 13.8. Expert Review Instructions . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . 56 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 58 14.1. Normative References . . . . . . . . . . . . . . . . . . 55
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 58 14.2. Informative References . . . . . . . . . . . . . . . . . 57
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 59 Appendix A. Scenario Examples . . . . . . . . . . . . . . . . . 59
Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 60 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 59
B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 60 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 60
B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 61 Appendix B. Deployment Examples . . . . . . . . . . . . . . . . 62
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 62 B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 62
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 62 B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 62
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 63 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 63
C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 64 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 63
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 66 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 65
C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 67 C.3. Test Vector 3: Key Derivation with ID Context . . . . . . 66
C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 68 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 68
C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 69 C.5. Test Vector 5: OSCORE Request, Client . . . . . . . . . . 69
C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 70 C.6. Test Vector 6: OSCORE Request, Client . . . . . . . . . . 70
Appendix D. Overview of Security Properties . . . . . . . . . . 71 C.7. Test Vector 7: OSCORE Response, Server . . . . . . . . . 71
D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 71 C.8. Test Vector 8: OSCORE Response with Partial IV, Server . 72
D.2. Protected Message Fields . . . . . . . . . . . . . . . . 72 Appendix D. Overview of Security Properties . . . . . . . . . . 74
D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 73 D.1. Supporting Proxy Operations . . . . . . . . . . . . . . . 74
D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 74 D.2. Protected Message Fields . . . . . . . . . . . . . . . . 74
Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 76 D.3. Uniqueness of (key, nonce) . . . . . . . . . . . . . . . 75
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 77 D.4. Unprotected Message Fields . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 77 Appendix E. CDDL Summary . . . . . . . . . . . . . . . . . . . . 79
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80
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 [RFC5246] 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
skipping to change at page 12, line 31 skipping to change at page 12, line 31
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. The contexts using the same Master Secret and Master Salt. This means
requirement that Sender ID SHALL be unique in the set of all security that Sender ID SHALL be unique in the set of all security contexts
contexts using the same Master Secret, Master Salt, and ID Context using the same Master Secret, Master Salt, and ID Context; such a
guarantees unique (key, nonce) pairs, which avoids nonce reuse. requirement guarantees unique (key, nonce) pairs, which avoids nonce
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. For AES-
CCM-16-64-128 the maximum length of Sender ID is 7 bytes. 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
skipping to change at page 16, line 15 skipping to change at page 16, line 15
4.1.3.1. Max-Age 4.1.3.1. Max-Age
An Inner Max-Age message field is used to indicate the maximum time a An Inner Max-Age message field is used to indicate the maximum time a
response may be cached by the client (as defined in [RFC7252]), end- response may be cached by the client (as defined in [RFC7252]), end-
to-end from the server to the client, taking into account that the to-end from the server to the client, taking into account that the
option is not accessible to proxies. The Inner Max-Age SHALL be option is not accessible to proxies. The Inner Max-Age SHALL be
processed by OSCORE as a normal Inner option, specified in processed by OSCORE as a normal Inner option, specified in
Section 4.1.1. Section 4.1.1.
An Outer Max-Age message field is used to avoid unnecessary caching An Outer Max-Age message field is used to avoid unnecessary caching
of OSCORE error responses at OSCORE-unaware intermediary nodes. A of error responses caused by OSCORE processing at OSCORE-unaware
server MAY set a Class U Max-Age message field with value zero to intermediary nodes. A server MAY set a Class U Max-Age message field
OSCORE error responses, which are described in Sections 7.4, 8.2, and with value zero to such error responses, described in Sections 7.4,
8.4. Such a message field is then processed according to 8.2, and 8.4, since these error responses are cacheable, but
Section 4.1.2. subsequent OSCORE requests would never create a hit in the
intermediary caching it. Setting the Outer Max-Age to zero relieves
the intermediary from uselessly caching responses. Successful OSCORE
responses do not need to include an Outer Max-Age option since the
responses appear to the OSCORE-unaware intermediary as 2.04 Changed
responses, which are non-cacheable (see Section 4.2).
Successful OSCORE responses do not need to include an Outer Max-Age The Outer Max-Age message field is processed according to
option since the responses are non-cacheable by construction (see Section 4.1.2.
Section 4.2).
4.1.3.2. Uri-Host and Uri-Port 4.1.3.2. Uri-Host and Uri-Port
When the Uri-Host and Uri-Port are set to their default values (see When the Uri-Host and Uri-Port are set to their default values (see
Section 5.10.1 [RFC7252]), they are omitted from the message Section 5.10.1 [RFC7252]), they are omitted from the message
(Section 5.4.4 of [RFC7252]), which is favorable both for overhead (Section 5.4.4 of [RFC7252]), which is favorable both for overhead
and privacy. and privacy.
In order to support forward proxy operations, Proxy-Scheme, Uri-Host, In order to support forward proxy operations, Proxy-Scheme, Uri-Host,
and Uri-Port need to be Class U. For the use of Proxy-Uri, see and Uri-Port need to be Class U. For the use of Proxy-Uri, see
skipping to change at page 19, line 25 skipping to change at page 19, line 28
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 in responses (with or
without the Observe option) to Observe registrations. without the Observe option) to Observe registrations, except for the
first response where Partial IV MAY be omitted.
[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).
4.1.3.5.1. Registrations and Cancellations 4.1.3.5.1. Registrations and Cancellations
The Inner and Outer Observe in the request MUST contain the Observe The Inner and Outer Observe in the request MUST contain the Observe
value of the original CoAP request; 0 (registration) or 1 value of the original CoAP request; 0 (registration) or 1
(cancellation). (cancellation).
Every time a client issues a new Observe request, a new Partial IV Every time a client issues a new Observe request, a new Partial IV
MUST be used (see Section 5), and so the payload and OSCORE option MUST be used (see Section 5), and so the payload and OSCORE option
are changed. The server uses the Partial IV of the new request as are changed. The server uses the Partial IV of the new request as
the 'request_piv' of all associated notifications (see Section 5.4). the 'request_piv' of all associated notifications (see Section 5.4).
The Partial IV of the registration is also used as 'request_piv' of
associated cancellations (see Section 5.4).
Intermediaries are not assumed to have access to the OSCORE security Intermediaries are not assumed to have access to the OSCORE security
context used by the endpoints, and thus cannot make requests or context used by the endpoints, and thus cannot make requests or
transform responses with the OSCORE option which verify at the transform responses with the OSCORE option which verify at the
receiving endpoint as coming from the other endpoint. This has the receiving endpoint as coming from the other endpoint. This has the
following consequences and limitations for Observe operations. following consequences and limitations for Observe operations.
o An intermediary node removing the Outer Observe 0 does not change o An intermediary node removing the Outer Observe 0 does not change
the registration request to a request without Observe (see the registration request to a request without Observe (see
Section 2 of [RFC7641]). Instead other means for cancellation may Section 2 of [RFC7641]). Instead other means for cancellation may
skipping to change at page 20, line 40 skipping to change at page 20, line 41
coming from the client. An application MAY decide to allow coming from the client. An application MAY decide to allow
intermediaries to cancel Observe registrations, e.g. to send intermediaries to cancel Observe registrations, e.g. to send
Observe with value 1 (see Section 3.6 of [RFC7641]), but that can Observe with value 1 (see Section 3.6 of [RFC7641]), but that can
also be done with other methods, e.g. reusing the Token in a also be done with other methods, e.g. reusing the Token in a
different request or sending a RST message. This is out of scope different request or sending a RST message. This is out of scope
for this specification. for this specification.
4.1.3.5.2. Notifications 4.1.3.5.2. Notifications
If the server accepts an Observe registration, a Partial IV MUST be If the server accepts an Observe registration, a Partial IV MUST be
included in all notifications (both successful and error). To included in all notifications (both successful and error), except for
protect against replay, the client SHALL maintain a Notification the first one where Partial IV MAY be omitted. To protect against
Number for each Observation it registers. The Notification Number is replay, the client SHALL maintain a Notification Number for each
a non-negative integer containing the largest Partial IV of the Observation it registers. The Notification Number is a non-negative
received notifications for the associated Observe registration. integer containing the largest Partial IV of the received
Further details of replay protection of notifications are specified notifications for the associated Observe registration. Further
in Section 7.4.1. details of replay protection of notifications are specified in
Section 7.4.1.
For notifications, the Inner Observe value MUST be empty (see For notifications, the Inner Observe value MUST be empty (see
Section 3.2 of [RFC7252]). The Outer Observe in a notification is Section 3.2 of [RFC7252]). The Outer Observe in a notification is
needed for intermediary nodes to allow multiple responses to one needed for intermediary nodes to allow multiple responses to one
request, and may be set to the value of Observe in the original CoAP request, and may be set to the value of Observe in the original CoAP
message. The client performs ordering of notifications and replay message. The client performs ordering of notifications and replay
protection by comparing their Partial IVs and SHALL ignore the outer protection by comparing their Partial IVs and SHALL ignore the outer
Observe value. Observe value.
If the client receives a response to an Observe request without an If the client receives a response to an Observe request without an
Inner Observe option, then it verifies the response as a non-Observe Inner Observe option, then it verifies the response as a non-Observe
response, as specified in Section 8.4. If the client receives a response, as specified in Section 8.4. If the client receives a
response to a non-Observe request with an Inner Observe option, then response to a non-Observe request with an Inner Observe option, then
it stops processing the message, as specified in Section 8.4. it stops processing the message, as specified in Section 8.4.
A client MUST consider the notification with the highest Partial IV A client MUST consider the notification with the highest Partial IV
as the freshest, regardless of the order of arrival. In order to as the freshest, regardless of the order of arrival. In order to
support existing Observe implementations the OSCORE client support existing Observe implementations the OSCORE client
implementation MAY set the Observe value to the three least implementation MAY set the Observe value to the three least
significant bytes of the Partial IV. significant bytes of the Partial IV; such an implementation needs to
make sure that the Observe value for an observe notification without
Partial IV is smaller than a notification with Partial IV.
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 27, line 48 skipping to change at page 27, line 48
o algorithms: contains (for extensibility) an array of algorithms, o algorithms: contains (for extensibility) an array of algorithms,
according to this specification only containing alg_aead. according to this specification only containing alg_aead.
o alg_aead: contains the AEAD Algorithm from the security context o alg_aead: contains the AEAD Algorithm from the security context
used for the exchange (see Section 3.1). used for the exchange (see Section 3.1).
o request_kid: contains the value of the 'kid' in the COSE object of o request_kid: contains the value of the 'kid' in the COSE object of
the request (see Section 5). the request (see Section 5).
o request_piv: contains the value of the 'Partial IV' in the COSE o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5), with one exception: in case object of the request (see Section 5).
of protection or verification of Observe cancellations, the
request_piv contains the value of the 'Partial IV' in the COSE
object of the corresponding registration (see Section 4.1.3.5.1).
o options: contains the Class I options (see Section 4.1.2) present o options: contains the Class I options (see Section 4.1.2) present
in the original CoAP message encoded as described in Section 3.1 in the original CoAP message encoded as described in Section 3.1
of [RFC7252], where the delta is the difference to the previously of [RFC7252], where the delta is the difference to the previously
included instance of class I option. included instance of class I option.
The oscore_version and algorithms parameters are established out-of- The oscore_version and algorithms parameters are established out-of-
band and are thus never transported in OSCORE, but the external_aad band 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.
skipping to change at page 29, line 17 skipping to change at page 29, line 17
|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 of flag bits encodes the following set of flags and o The first byte, called OSCORE Octet, encodes the following set of
the length of the Partial IV parameter: flag 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
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).
o The remaining bytes encode the value of the kid, if the kid is o The remaining bytes encode the value of the kid, if the kid is
skipping to change at page 32, line 47 skipping to change at page 32, line 47
[I-D.mattsson-core-coap-actuators] from on-path attackers and [I-D.mattsson-core-coap-actuators] from on-path attackers and
compromised intermediaries, OSCORE binds responses to the requests by compromised intermediaries, OSCORE binds responses to the requests by
including the kid and Partial IV of the request in the AAD of the including the kid and Partial IV of the request in the AAD of the
response. The server therefore needs to store the kid and Partial IV response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent. of the request until all responses have been sent.
7.2. Sequence Numbers 7.2. Sequence Numbers
An AEAD nonce MUST NOT be used more than once per AEAD key. The An AEAD nonce MUST NOT be used more than once per AEAD key. The
uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in
particular depends on a correct usage of Partial IVs. If messages particular depends on a correct usage of Partial IVs (which encode
are processed concurrently, the operation of reading and increasing the Sender Sequence Numbers, see Section 5). If messages are
the Sender Sequence Number MUST be atomic. processed concurrently, the operation of reading and increasing the
Sender Sequence Number MUST be atomic.
7.2.1. Maximum Sequence Number 7.2.1. Maximum Sequence Number
The maximum Sender Sequence Number is algorithm dependent (see The maximum Sender Sequence Number is algorithm dependent (see
Section 12), and SHALL be less than 2^40. If the Sender Sequence Section 12), and SHALL be less than 2^40. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more Number exceeds the maximum, the endpoint MUST NOT process any more
messages with the given Sender Context. If necessary, the endpoint messages with the given Sender Context. If necessary, the endpoint
SHOULD acquire a new security context before this happens. The SHOULD acquire a new security context before this happens. The
latter is out of scope of this document. latter is out of scope of this document.
skipping to change at page 34, line 21 skipping to change at page 34, line 21
The operation of validating the Partial IV and updating the replay The operation of validating the Partial IV and updating the replay
protection MUST be atomic. protection MUST be atomic.
7.4.1. Replay Protection of Notifications 7.4.1. Replay Protection of Notifications
The following applies additionally when Observe is supported. The following applies additionally when Observe is supported.
The Notification Number is initialized to the Partial IV of the first The Notification Number is initialized to the Partial IV of the first
successfully verified notification in response to the registration successfully verified notification in response to the registration
request. A client receiving a notification SHALL compare the Partial request. A client MUST only accept at most one Observe notifications
IV with the Notification Number associated to that Observe without Partial IV, and treat it as the oldest notification received.
registration. The client MUST stop processing notifications with a A client receiving a notification containing a Partial IV SHALL
Partial IV which has been previously received. Applications MAY compare the Partial IV with the Notification Number associated to
decide that a client only processes notifications which have greater that Observe registration. The client MUST stop processing
Partial IV than the Notification Number. notifications with a Partial IV which has been previously received.
Applications MAY decide that a client only processes notifications
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 key, or from
accepting replayed messages, an endpoint needs to handle the accepting replayed messages, an endpoint needs to handle the
skipping to change at page 38, line 38 skipping to change at page 38, line 44
used, the Partial IV MUST NOT be included in the message. used, the Partial IV MUST NOT be included in the message.
5. Format the OSCORE message according to Section 4. The OSCORE 5. Format the OSCORE message according to Section 4. The OSCORE
option is added (see Section 4.1.2). option is added (see Section 4.1.2).
8.3.1. Supporting Observe 8.3.1. Supporting Observe
If Observe is supported, insert the following step between step 2 and If Observe is supported, insert the following step between step 2 and
3 of Section 8.3: 3 of Section 8.3:
A. If the request was a registration, encode the Partial IV (Sender A. If the response is an observe notification:
Sequence Number in network byte order) and increment the Sender
Sequence Number by one. Compute the AEAD nonce from the Sender ID, o If the response is the first notification:
Common IV, and Partial IV, then go to 4.
* compute the AEAD nonce as described in Section 5.2:
+ Either use the nonce from the request, or
+ Encode the Partial IV (Sender Sequence Number in network
byte order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV.
Then go to 4.
o If the response is not the first notification:
* encode the Partial IV (Sender Sequence Number in network byte
order) and increment the Sender Sequence Number by one.
Compute the AEAD nonce from the Sender ID, Common IV, and
Partial IV, then go to 4.
8.4. Verifying the Response 8.4. Verifying the Response
A client receiving a response containing the OSCORE option SHALL A client receiving a response containing the OSCORE option SHALL
perform the following steps: perform the following steps:
1. Discard Code and all class E options (marked in Figure 5 with 'x' 1. Discard Code and all class E options (marked in Figure 5 with 'x'
in column E) present in the received message. For example, ETag in column E) present in the received message. For example, ETag
Outer option is discarded, as well as Max-Age Outer option. Outer option is discarded, as well as Max-Age Outer option.
skipping to change at page 39, line 51 skipping to change at page 40, line 25
have been received (see Section 4.1.3.4). have been received (see Section 4.1.3.4).
8.4.2. Supporting Observe 8.4.2. Supporting Observe
If Observe is supported: If Observe is supported:
Insert the following step between step 5 and step 6: Insert the following step between step 5 and step 6:
A. If the request was an Observe registration, then: A. If the request was an Observe registration, then:
o If the Partial IV is not present in the response, and either the o If the Partial IV is not present in the response, and Inner
client has previously received a successful notification to the Observe is present, and the nonce from the request was already
registration (active observation) or Inner Observe is present, used once, then go to 8.
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 54, line 22 skipping to change at page 54, line 22
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
It is requested that IANA create a new registry entitled "OSCORE
Octet". 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:
o bit position: This indicates the position of the bit in the OSCORE
Octet, starting at 0 for the most significant bit. The bit
position must be an integer or a range of integers, in the range 0
to 63.
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
protocol. Names are to be unique in the table.
o description: This contains a brief description of the use of the
bit.
o specification: This contains a pointer to the specification
defining the entry.
The initial contents of the registry can be found in Figure 12. The
specification column for all rows in that table should be this
document. Additionally, the entry with Bit Position of 0 is to be
marked as 'Reserved'. This entry is going to be specified in a
future document, and will be used to expand the OSCORE Octet in
Section 6.1, so that entries 8-63 of the registry are defined.
+--------------+-------------+---------------------+-------------------+
| Bit Position | Name | Description | Specification |
+--------------+-------------+---------------------+-------------------+
| 0 | Reserved | | |
+--------------+-------------+---------------------+-------------------+
| 3 | Kid Context | Set to 1 if kid | [[this document]] |
| | Flag | context is present | |
| | | in the compressed | |
| | | COSE object | |
+--------------+-------------+---------------------+-------------------+
| 4 | Kid Flag | Set to 1 if kid is | [[this document]] |
| | | present in the com- | |
| | | pressed COSE object | |
+--------------+-------------+---------------------+-------------------+
| 5-7 | Partial IV | Encodes the Partial | [[this document]] |
| | Length | IV length; can have | |
| | | value 0 to 5 | |
+--------------+-------------+---------------------+-------------------+
Figure 12
13.8. Expert Review Instructions
The expert reviewers for the registry defined in this document are
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
duplicate one that is already registered, and that the registered
point is likely to be used in deployments. They are furthermore
expected to check the clarity of purpose and use of the requested
code points. Experts should take into account the expected usage of
entries when approving point assignment, and the length of the
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
on. Experts should block registration for entries 8-63 until these
points are defined (i.e. until the mechanism for the OSCORE Octet
expansion via bit 0 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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
skipping to change at page 56, line 28 skipping to change at page 57, line 51
[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
for CoAP End-To-End Security", draft-hartke-core-e2e- for CoAP End-To-End Security", draft-hartke-core-e2e-
security-reqs-03 (work in progress), July 2017. security-reqs-03 (work in progress), July 2017.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-12 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-13
(work in progress), May 2018. (work in progress), July 2018.
[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-01 (work in progress), March 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-02 express CBOR data structures", draft-ietf-cbor-cddl-03
(work in progress), February 2018. (work in progress), July 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-01 (work in Request-Tag", draft-ietf-core-echo-request-tag-02 (work in
progress), March 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-01 (work in progress), March 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.
[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
skipping to change at page 58, line 44 skipping to change at page 60, line 30
| | 2.04 | Token: 0x7b | | 2.04 | Token: 0x7b
| | | OSCORE: - | | | OSCORE: -
| | | Payload: {Code:2.05, "0"} | | | Payload: {Code:2.05, "0"}
| | | | | |
|<------+ | Code: 2.04 (Changed) |<------+ | Code: 2.04 (Changed)
| 2.04 | | Token: 0x8c | 2.04 | | Token: 0x8c
| | | OSCORE: - | | | OSCORE: -
| | | Payload: {Code:2.05, "0"} | | | Payload: {Code:2.05, "0"}
| | | | | |
Figure 12: Secure Access to Sensor. Square brackets [ ... ] indicate Figure 13: 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 60, line 15 skipping to change at page 61, line 48
| | | 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 13: Secure Subscribe to Sensor. Square brackets [ ... ] Figure 14: 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 44 skipping to change at page 64, line 22
o info (for Common IV): 0x8540f60a6249560d (8 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs: Outputs:
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
sender and recipient):
o sender nonce: 0x4622d4dd6d944168eefb54987c
o recipient nonce: 0x4722d4dd6d944169eefb54987c
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)
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)
skipping to change at page 63, line 17 skipping to change at page 65, line 4
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
sender and recipient):
o sender nonce: 0x4722d4dd6d944169eefb54987c
o recipient nonce: 0x4622d4dd6d944168eefb54987c
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. KDF, 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)
skipping to change at page 64, line 5 skipping to change at page 65, line 46
o info (for Common IV): 0x8540f60a6249560d (8 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs: Outputs:
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
sender and recipient):
o sender nonce: 0xbf35ae297d2dace910c52e99f9
o recipient nonce: 0xbf35ae297d2dace810c52e99f9
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 64, line 31 skipping to change at page 66, line 31
o info (for Common IV): 0x8540f60a6249560d (8 bytes) o info (for Common IV): 0x8540f60a6249560d (8 bytes)
Outputs: Outputs:
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
sender and recipient):
o sender nonce: 0xbf35ae297d2dace810c52e99f9
o recipient nonce: 0xbf35ae297d2dace910c52e99f9
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. KDF.
C.3.1. Client C.3.1. Client
Inputs: Inputs:
skipping to change at page 65, line 21 skipping to change at page 67, line 27
bytes) bytes)
Outputs: Outputs:
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
sender and recipient):
o sender nonce: 0x2ca58fb85ff1b81c0b7181b85e
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 66, line 4 skipping to change at page 68, line 16
bytes) bytes)
o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16 o info (for Common IV): 0x85404837cbf3210017a2d30a6249560d (16
bytes) bytes)
Outputs: Outputs:
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
sender and recipient):
o sender nonce: 0x2da58fb85ff1b81d0b7181b85e
o recipient nonce: 0x2ca58fb85ff1b81c0b7181b85e
C.4. Test Vector 4: OSCORE Request, Client C.4. Test Vector 4: OSCORE Request, Client
This section contains a test vector for an OSCORE protected CoAP GET This section contains a test vector for an OSCORE protected CoAP GET
request using the security context derived in Appendix C.1. The request using the security context derived in Appendix C.1. The
unprotected request only contains the Uri-Path and Uri-Host options. unprotected request only contains the Uri-Path and Uri-Host options.
Unprotected CoAP request: Unprotected CoAP request:
0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes) 0x44015d1f00003974396c6f63616c686f737483747631 (22 bytes)
Common Context: Common Context:
skipping to change at page 73, line 39 skipping to change at page 76, line 16
notifications): notifications):
o ID_PIV = Sender ID of the encrypting endpoint o ID_PIV = Sender ID of the encrypting endpoint
o PIV = current Partial IV of the encrypting endpoint o PIV = current Partial IV of the encrypting endpoint
Since the encrypting endpoint steps the Partial IV for each use, the Since the encrypting endpoint steps the Partial IV for each use, the
nonces used in case A are all unique as long as the number of nonces used in case A are all unique as long as the number of
encrypted messages is kept within the required range (Section 7.2.1). encrypted messages is kept within the required range (Section 7.2.1).
B. For responses without Partial IV (subset of cases with single B. For responses without Partial IV (e.g. single response to a
response to a request): request):
o ID_PIV = Sender ID of the endpoint generating the request o ID_PIV = Sender ID of the endpoint generating the request
o PIV = Partial IV of the request o PIV = Partial IV of the request
Since the Sender IDs are unique, ID_PIV is different from the Sender Since the Sender IDs are unique, ID_PIV is different from the Sender
ID of the encrypting endpoint. Therefore, the nonces in case B are ID of the encrypting endpoint. Therefore, the nonces in case B are
different compared to nonces in case A, where the encrypting endpoint different compared to nonces in case A, where the encrypting endpoint
generated the Partial IV. Since the Partial IV of the request is generated the Partial IV. Since the Partial IV of the request is
verified for replay (Section 7.4) associated to this Recipient verified for replay (Section 7.4) associated to this Recipient
skipping to change at page 75, line 35 skipping to change at page 78, line 12
the last hop, but not what was requested by the client or what was the last hop, but not what was requested by the client or what was
used in previous hops. used in previous hops.
o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/
Uri-Port may be changed by an adversary, and the application needs Uri-Port may be changed by an adversary, and the application needs
to handle the consequences of that (see Section 4.1.3.2). The to handle the consequences of that (see Section 4.1.3.2). The
Uri-Host may either be omitted, reveal information equivalent to Uri-Host may either be omitted, reveal information equivalent to
that of the IP address or more privacy-sensitive information, that of the IP address or more privacy-sensitive information,
which is discouraged. which is discouraged.
o Observe. The Outer Observe option is intended for an OSCORE- o Observe. The Outer Observe option is intended for a proxy to
unaware proxy to support forwarding of Observe messages, but is support forwarding of Observe messages, but is ignored by the
ignored by the endpoints since the Inner Observe determines the endpoints since the Inner Observe determines the processing in the
processing in the endpoints. Since the Partial IV provides endpoints. Since the Partial IV provides absolute ordering of
absolute ordering of notifications it is not possible for an notifications it is not possible for an intermediary to spoof
intermediary to spoof reordering (see Section 4.1.3.5). The size reordering (see Section 4.1.3.5). The absence of Partial IV,
and distributions of notifications over time may reveal since only allowed for the first notification, does not prevent
information about the content or nature of the notifications. correct ordering of notifications. The size and distributions of
notifications over time may reveal information about the content
or nature of the notifications. Cancellations (Section 4.1.3.5.1)
are not bound to the corresponding registrations in the same way
responses are bound to requests in OSCORE (see Appendix D.2), but
that does not open up for attacks based on mismatched
cancellations, since [RFC7641] specifies that for cancellations to
be accepted, all options except for ETags MUST be the same (see
Section 3.6 of [RFC7641]). For different target resources, the
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
 End of changes. 46 change blocks. 
106 lines changed or deleted 254 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/