Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8613

Object Security for Constrained RESTful Environments (OSCORE)

Pages: 94
Proposed Standard
Updates:  7252
Part 4 of 6 – Pages 51 to 67
First   Prev   Next

Top   ToC   RFC8613 - Page 51   prevText

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.
Top   ToC   RFC8613 - Page 52
   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].
Top   ToC   RFC8613 - Page 53

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).
Top   ToC   RFC8613 - Page 54
   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
Top   ToC   RFC8613 - Page 55
   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 document

13.2. CoAP Option Numbers Registry

The OSCORE option has been added to the "CoAP Option Numbers" registry: +--------+-----------------+-------------------+ | Number | Name | Reference | +--------+-----------------+-------------------+ | 9 | OSCORE | [RFC8613] | +--------+-----------------+-------------------+
Top   ToC   RFC8613 - Page 56
   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] | +------------+--------+---------------------+-------------------+
Top   ToC   RFC8613 - Page 57

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
Top   ToC   RFC8613 - Page 58
     Person & email address to contact for further information:
        IESG <>

     Intended usage: COMMON

     Restrictions on usage: N/A

     Author: Goeran Selander <>

     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.
Top   ToC   RFC8613 - Page 59
   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
Top   ToC   RFC8613 - Page 60
   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, <>. [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <>. [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <>. [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <>. [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, <>. [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, <>.
Top   ToC   RFC8613 - Page 61
   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,

   [RFC7959]  Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
              the Constrained Application Protocol (CoAP)", RFC 7959,
              DOI 10.17487/RFC7959, August 2016,

   [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,

   [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,

   [RFC8152]  Schaad, J., "CBOR Object Signing and Encryption (COSE)",
              RFC 8152, DOI 10.17487/RFC8152, July 2017,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,

   [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,

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
Top   ToC   RFC8613 - Page 62
   [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, <>.

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.
Top   ToC   RFC8613 - Page 63
   [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.

              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,

   [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,

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <>.
Top   ToC   RFC8613 - Page 64
   [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, <>.

   [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,
Top   ToC   RFC8613 - Page 65

Appendix A. Scenario Examples

This section gives examples of OSCORE, targeting scenarios in Section 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.
Top   ToC   RFC8613 - Page 66
   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"} ... ... ... | | |
Top   ToC   RFC8613 - Page 67
        |       |<------+            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

   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)

Next Section