RFC 8613
Object Security for Constrained RESTful Environments (OSCORE)
12. Security Considerations
An overview of the security properties is given in Appendix D.12.1. End-to-end Protection
In scenarios with intermediary nodes such as proxies or gateways, transport layer security such as (D)TLS only protects data hop-by- hop. As a consequence, the intermediary nodes can read and modify any information. The trust model where all intermediary nodes are considered trustworthy is problematic, not only from a privacy perspective, but also from a security perspective, as the intermediaries are free to delete resources on sensors and falsify commands to actuators (such as "unlock door", "start fire alarm", "raise bridge"). Even in the rare cases where all the owners of the intermediary nodes are fully trusted, attacks and data breaches make such an architecture brittle. (D)TLS protects hop-by-hop the entire message. OSCORE protects end- to-end all information that is not required for proxy operations (see Section 4). (D)TLS and OSCORE can be combined, thereby enabling end- to-end security of the message payload, in combination with hop-by- hop protection of the entire message, during transport between endpoint and intermediary node. In particular, when OSCORE is used with HTTP, the additional TLS protection of HTTP hops is RECOMMENDED, e.g., between an HTTP endpoint and a proxy translating between HTTP and CoAP.
Applications need to consider that certain message fields and messages types are not protected end-to-end and may be spoofed or manipulated. The consequences of unprotected message fields are analyzed in Appendix D.5.12.2. Security Context Establishment
The use of COSE_Encrypt0 and AEAD to protect messages as specified in this document requires an established security context. The method to establish the security context described in Section 3.2 is based on a common Master Secret and unique Sender IDs. The necessary input parameters may be preestablished or obtained using a key establishment protocol augmented with establishment of Sender/ Recipient ID, such as a key exchange protocol or the OSCORE profile of the Authentication and Authorization for Constrained Environments (ACE) framework [OSCORE-PROFILE]. Such a procedure must ensure that the requirements of the security context parameters for the intended use are complied with (see Section 3.3) even in error situations. While recipient IDs are allowed to coincide between different security contexts (see Section 3.3), this may cause a server to process multiple verifications before finding the right security context or rejecting a message. Considerations for deploying OSCORE with a fixed Master Secret are given in Appendix B.12.3. Master Secret
OSCORE uses HKDF [RFC5869] and the established input parameters to derive the security context. The required properties of the security context parameters are discussed in Section 3.3; in this section, we focus on the Master Secret. In this specification, HKDF denotes the composition of the expand and extract functions as defined in [RFC5869] and the Master Secret is used as Input Keying Material (IKM). Informally, HKDF takes as source an IKM containing some good amount of randomness but not necessarily distributed uniformly (or for which an attacker has some partial knowledge) and derive from it one or more cryptographically strong secret keys [RFC5869]. Therefore, the main requirement for the OSCORE Master Secret, in addition to being secret, is that it have a good amount of randomness. The selected key establishment schemes must ensure that the necessary properties for the Master Secret are fulfilled. For pre-shared key deployments and key transport solutions such as [OSCORE-PROFILE], the Master Secret can be generated offline using a good random number generator. Randomness requirements for security are described in [RFC4086].
12.4. Replay Protection
Replay attacks need to be considered in different parts of the implementation. Most AEAD algorithms require a unique nonce for each message, for which the Sender Sequence Numbers in the COSE message field 'Partial IV' is used. If the recipient accepts any sequence number larger than the one previously received, then the problem of sequence number synchronization is avoided. With reliable transport, it may be defined that only messages with sequence numbers that are equal to the previous sequence number + 1 are accepted. An adversary may try to induce a device reboot for the purpose of replaying a message (see Section 7.5). Note that sharing a security context between servers may open up for replay attacks, for example, if the Replay Windows are not synchronized.12.5. Client Aliveness
A verified OSCORE request enables the server to verify the identity of the entity who generated the message. However, it does not verify that the client is currently involved in the communication, since the message may be a delayed delivery of a previously generated request, 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 client (see [CoAP-ECHO-REQ-TAG]).12.6. Cryptographic Considerations
The maximum Sender Sequence Number is dependent on the AEAD algorithm. The maximum Sender Sequence Number is 2^40 - 1, or any algorithm-specific lower limit, after which a new security context must be generated. The mechanism to build the AEAD nonce (Section 5.2) assumes that the nonce is at least 56 bits, and the Partial IV is at most 40 bits. The mandatory-to-implement AEAD 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 repeatedly encrypted by many different users with distinct AEAD keys, the AEAD nonce is formed by mixing the sequence number with a secret per-context initialization vector (Common IV) derived along with the keys (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key derivation (see [MF00] for an overview). The Master Secret, Sender Key, Recipient Key, and Common IV must be secret, the rest of the parameters may be public. The Master Secret must have a good amount of randomness (see Section 12.3).
The ID Context, Sender ID, and Partial IV are always at least implicitly integrity protected, as manipulation leads to the wrong nonce or key being used and therefore results in decryption failure.12.7. Message Segmentation
The Inner Block options enable the sender to split large messages into OSCORE-protected blocks such that the receiving endpoint can verify blocks before having received the complete message. The Outer Block options allow for arbitrary proxy fragmentation operations that cannot be verified by the endpoints but that can, by policy, be restricted in size since the Inner Block options allow for secure fragmentation of very large messages. A maximum message size (above which the sending endpoint fragments the message and the receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery.12.8. Privacy Considerations
Privacy threats executed through intermediary nodes are considerably reduced by means of OSCORE. End-to-end integrity protection and encryption of the message payload and all options that are not used for proxy operations provide mitigation against attacks on sensor and actuator communication, which may have a direct impact on the personal sphere. The unprotected options (Figure 5) may reveal privacy-sensitive information, see Appendix D.5. CoAP headers sent in plaintext allow, for example, matching of CON and ACK (CoAP Message Identifier), matching of request and responses (Token) and traffic analysis. OSCORE does not provide protection for HTTP header fields that are not both CoAP-mappable and Class E. The HTTP message fields that are visible to on-path entities are only used for the purpose of transporting the OSCORE message, whereas the application-layer message is encoded in CoAP and encrypted. COSE message fields, i.e., the OSCORE option, may reveal information about the communicating endpoints. For example, 'kid' and 'kid context', which are intended to help the server find the right context, may reveal information about the client. Tracking 'kid' and 'kid context' to one server may be used for correlating requests from one client. Unprotected error messages reveal information about the security state in the communication between the endpoints. Unprotected signaling messages reveal information about the reliable transport
used on a leg of the path. Using the mechanisms described in Section 7.5 may reveal when a device goes through a reboot. This can be mitigated by the device storing the precise state of Sender Sequence Number and Replay Window on a clean shutdown. The length of message fields can reveal information about the message. Applications may use a padding scheme to protect against traffic analysis.13. IANA Considerations
13.1. COSE Header Parameters Registry
The 'kid context' parameter has been added to the "COSE Header Parameters" registry: o Name: kid context o Label: 10 o Value Type: bstr o Value Registry: o Description: Identifies the context for the key identifier o Reference: Section 5.1 of this document13.2. CoAP Option Numbers Registry
The OSCORE option has been added to the "CoAP Option Numbers" registry: +--------+-----------------+-------------------+ | Number | Name | Reference | +--------+-----------------+-------------------+ | 9 | OSCORE | [RFC8613] | +--------+-----------------+-------------------+
Furthermore, the following existing entries in the "CoAP Option
Numbers" registry have been updated with a reference to the document
specifying OSCORE processing of that option:
+--------+-----------------+-------------------------------+
| Number | Name | Reference |
+--------+-----------------+-------------------------------+
| 1 | If-Match | [RFC7252] [RFC8613] |
| 3 | Uri-Host | [RFC7252] [RFC8613] |
| 4 | ETag | [RFC7252] [RFC8613] |
| 5 | If-None-Match | [RFC7252] [RFC8613] |
| 6 | Observe | [RFC7641] [RFC8613] |
| 7 | Uri-Port | [RFC7252] [RFC8613] |
| 8 | Location-Path | [RFC7252] [RFC8613] |
| 11 | Uri-Path | [RFC7252] [RFC8613] |
| 12 | Content-Format | [RFC7252] [RFC8613] |
| 14 | Max-Age | [RFC7252] [RFC8613] |
| 15 | Uri-Query | [RFC7252] [RFC8613] |
| 17 | Accept | [RFC7252] [RFC8613] |
| 20 | Location-Query | [RFC7252] [RFC8613] |
| 23 | Block2 | [RFC7959] [RFC8323] [RFC8613] |
| 27 | Block1 | [RFC7959] [RFC8323] [RFC8613] |
| 28 | Size2 | [RFC7959] [RFC8613] |
| 35 | Proxy-Uri | [RFC7252] [RFC8613] |
| 39 | Proxy-Scheme | [RFC7252] [RFC8613] |
| 60 | Size1 | [RFC7252] [RFC8613] |
| 258 | No-Response | [RFC7967] [RFC8613] |
+--------+-----------------+-------------------------------+
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
The OSCORE option has been added to the "CoAP Signaling Option
Numbers" registry:
+------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+
| 7.xx (all) | 9 | OSCORE | [RFC8613] |
+------------+--------+---------------------+-------------------+
13.4. Header Field Registrations
The HTTP OSCORE header field has been added to the "Message Headers" registry: +-------------------+----------+----------+---------------------+ | Header Field Name | Protocol | Status | Reference | +-------------------+----------+----------+---------------------+ | OSCORE | http | standard | [RFC8613], | | | | | Section 11.1 | +-------------------+----------+----------+---------------------+13.5. Media Type Registration
This section registers the 'application/oscore' media type in the "Media Types" registry. This media type is used to indicate that the content is an OSCORE message. The OSCORE body cannot be understood without the OSCORE header field value and the security context. Type name: application Subtype name: oscore Required parameters: N/A Optional parameters: N/A Encoding considerations: binary Security considerations: See the Security Considerations section of [RFC8613]. Interoperability considerations: N/A Published specification: [RFC8613] Applications that use this media type: IoT applications sending security content over HTTP(S) transports. Fragment identifier considerations: N/A Additional information: * Deprecated alias names for this type: N/A * Magic number(s): N/A * File extension(s): N/A * Macintosh file type code(s): N/A
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Intended usage: COMMON
Restrictions on usage: N/A
Author: Goeran Selander <goran.selander@ericsson.com>
Change Controller: IESG
Provisional registration? No
13.6. CoAP Content-Formats Registry
This section registers the media type 'application/oscore' media type
in the "CoAP Content-Formats" registry. This Content-Format for the
OSCORE payload is defined for potential future use cases and SHALL
NOT be used in the OSCORE message. The OSCORE payload cannot be
understood without the OSCORE option value and the security context.
+----------------------+----------+----------+-------------------+
| Media Type | Encoding | ID | Reference |
+----------------------+----------+----------+-------------------+
| application/oscore | | 10001 | [RFC8613] |
+----------------------+----------+----------+-------------------+
13.7. OSCORE Flag Bits Registry
This document defines a subregistry for the OSCORE flag bits within
the "CoRE Parameters" registry. The name of the subregistry is
"OSCORE Flag Bits". The registry has been created with the Expert
Review policy [RFC8126]. Guidelines for the experts are provided in
Section 13.8.
The columns of the registry are as follows:
o Bit Position: This indicates the position of the bit in the set of
OSCORE flag bits, starting at 0 for the most significant bit. The
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 Reference: This contains a pointer to the specification defining
the entry.
The initial contents of the registry are in the table below. The
reference column for all rows is this document. The entries with Bit
Position of 0 and 1 are marked as 'Reserved'. The entry with Bit
Position of 1 will be specified in a future document and will be used
to expand the space for the OSCORE flag bits in Section 6.1, so that
entries 8-63 of the registry are defined.
+--------------+-------------+-----------------------------+-----------+
| Bit Position | Name | Description | Reference |
+--------------+-------------+-----------------------------+-----------+
| 0 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 1 | Reserved | | |
+--------------+-------------+-----------------------------+-----------+
| 2 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
| 3 | Kid Context | Set to 1 if kid context | [RFC8613] |
| | Flag | is present in the | |
| | | compressed COSE object | |
+--------------+-------------+-----------------------------+-----------+
| 4 | Kid Flag | Set to 1 if kid is present | [RFC8613] |
| | | in the compressed COSE | |
| | | object | |
+--------------+-------------+-----------------------------+-----------+
| 5-7 | Partial IV | Encodes the Partial IV | [RFC8613] |
| | Length | length; can have value | |
| | | 0 to 5 | |
+--------------+-------------+-----------------------------+-----------+
| 8-63 | Unassigned | | |
+--------------+-------------+-----------------------------+-----------+
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
not be solved better 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 flag bits expansion via bit 1 is specified).14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <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 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>. [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>. [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>. [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, <https://www.rfc-editor.org/info/rfc8075>. [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, <https://www.rfc-editor.org/info/rfc8132>. [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, July 2017, <https://www.rfc-editor.org/info/rfc8152>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>. [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <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>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.14.2. Informative References
[ACE-OAuth] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", Work in Progress, draft-ietf-ace- oauth-authz-24, March 2019. [CoAP-802.15.4] Bormann, C., "Constrained Application Protocol (CoAP) over IEEE 802.15.4 Information Element for IETF", Work in Progress, draft-bormann-6lo-coap-802-15-ie-00, April 2016. [CoAP-Actuators] Mattsson, J., Fornehed, J., Selander, G., Palombini, F., and C. Amsuess, "Controlling Actuators with CoAP", Work in Progress, draft-mattsson-core-coap-actuators-06, September 2018. [CoAP-E2E-Sec] Selander, G., Palombini, F., and K. Hartke, "Requirements for CoAP End-To-End Security", Work in Progress, draft- hartke-core-e2e-security-reqs-03, July 2017. [CoAP-ECHO-REQ-TAG] Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, draft-ietf-core-echo-request-tag-04, March 2019. [Group-OSCORE] Tiloca, M., Selander, G., Palombini, F., and J. Park, "Group OSCORE - Secure Group Communication for CoAP", Work in Progress, draft-ietf-core-oscore-groupcomm-04, March 2019. [IV-GEN] McGrew, D., "Generation of Deterministic Initialization Vectors (IVs) and Nonces", Work in Progress, draft-mcgrew- iv-gen-03, October 2013.
[MF00] McGrew, D. and S. Fluhrer, "Attacks on Additive Encryption of Redundant Plaintext and Implications on Internet Security", Proceedings of the Seventh Annual Workshop on Selected Areas in Cryptography (SAC 2000) Springer- Verlag., pp. 14-28, 2000. [OSCORE-PROFILE] Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, "OSCORE profile of the Authentication and Authorization for Constrained Environments Framework", Work in Progress, draft-ietf-ace-oscore-profile-07, February 2019. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2010. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>. [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/info/rfc7967>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Scenario Examples
This section gives examples of OSCORE, targeting scenarios in Section 2.2.1.1 of [CoAP-E2E-Sec]. The message exchanges are made, based on the assumption that there is a security context established between client and server. For simplicity, these examples only indicate the content of the messages without going into detail of the (compressed) COSE message format.A.1. Secure Access to Sensor
This example illustrates a client requesting the alarm status from a server. Client Proxy Server | | | +------>| | Code: 0.02 (POST) | POST | | Token: 0x8c | | | OSCORE: [kid:5f, Partial IV:42] | | | Payload: {Code:0.01, | | | Uri-Path:"alarm_status"} | | | | +------>| Code: 0.02 (POST) | | POST | Token: 0x7b | | | OSCORE: [kid:5f, Partial IV:42] | | | Payload: {Code:0.01, | | | Uri-Path:"alarm_status"} | | | | |<------+ Code: 2.04 (Changed) | | 2.04 | Token: 0x7b | | | OSCORE: - | | | Payload: {Code:2.05, "0"} | | | |<------+ | Code: 2.04 (Changed) | 2.04 | | Token: 0x8c | | | OSCORE: - | | | Payload: {Code:2.05, "0"} | | | Square brackets [ ... ] indicate content of compressed COSE object. Curly brackets { ... } indicate encrypted data. Figure 12: Secure Access to Sensor The CoAP request/response Codes are encrypted by OSCORE and only dummy Codes (POST/Changed) are visible in the header of the OSCORE message. The option Uri-Path ("alarm_status") and payload ("0") are encrypted.
The COSE header of the request contains an identifier (5f), indicating which security context was used to protect the message and a Partial IV (42). The server verifies the request as specified in Section 8.2. The client verifies the response as specified in Section 8.4.A.2. Secure Subscribe to Sensor
This example illustrates a client requesting subscription to a blood sugar measurement resource (GET /glucose), first receiving the value 220 mg/dl and then a second value 180 mg/dl. Client Proxy Server | | | +------>| | Code: 0.05 (FETCH) | FETCH | | Token: 0x83 | | | Observe: 0 | | | OSCORE: [kid:ca, Partial IV:15] | | | Payload: {Code:0.01, | | | Observe:0, | | | Uri-Path:"glucose"} | | | | +------>| Code: 0.05 (FETCH) | | FETCH | Token: 0xbe | | | Observe: 0 | | | OSCORE: [kid:ca, Partial IV:15] | | | Payload: {Code:0.01, | | | Observe:0, | | | Uri-Path:"glucose"} | | | | |<------+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Observe: 7 | | | OSCORE: - | | | Payload: {Code:2.05, | | | Observe:-, | | | Content-Format:0, "220"} | | | |<------+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Observe: 7 | | | OSCORE: - | | | Payload: {Code:2.05, | | | Observe:-, | | | Content-Format:0, "220"} ... ... ... | | |
| |<------+ Code: 2.05 (Content) | | 2.05 | Token: 0xbe | | | Observe: 8 | | | OSCORE: [Partial IV:36] | | | Payload: {Code:2.05, | | | Observe:-, | | | Content-Format:0, "180"} | | | |<------+ | Code: 2.05 (Content) | 2.05 | | Token: 0x83 | | | Observe: 8 | | | OSCORE: [Partial IV:36] | | | Payload: {Code:2.05, | | | Observe:-, | | | Content-Format:0, "180"} | | | Square brackets [ ... ] indicate content of compressed COSE object header. Curly brackets { ... } indicate encrypted data. Figure 13: Secure Subscribe to Sensor The dummy Codes (FETCH/Content) are used to allow forwarding of Observe messages. The options Content-Format (0) and the payload ("220" and "180") are encrypted. The COSE header of the request contains an identifier (ca), indicating the security context used to protect the message and a Partial IV (15). The COSE header of the second response contains the Partial IV (36). The first response uses the Partial IV of the request. The server verifies that the Partial IV has not been received before. The client verifies that the responses are bound to the request and that the Partial IVs are greater than any Partial IV previously received in a response bound to the request, except for the notification without Partial IV, which is considered the oldest.
(next page on part 5)
