idnits 2.17.1 draft-ietf-core-object-security-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2598 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-09 == Outdated reference: A later version (-03) exists of draft-hartke-core-e2e-security-reqs-02 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-05 == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-07 == Outdated reference: A later version (-06) exists of draft-mattsson-core-coap-actuators-02 == Outdated reference: A later version (-06) exists of draft-seitz-ace-oscoap-profile-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-04 == Outdated reference: A later version (-04) exists of draft-tiloca-core-multicast-oscoap-00 Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group G. Selander 3 Internet-Draft J. Mattsson 4 Intended status: Standards Track F. Palombini 5 Expires: September 14, 2017 Ericsson AB 6 L. Seitz 7 SICS Swedish ICT 8 March 13, 2017 10 Object Security of CoAP (OSCOAP) 11 draft-ietf-core-object-security-02 13 Abstract 15 This document defines Object Security of CoAP (OSCOAP), a method for 16 application layer protection of the Constrained Application Protocol 17 (CoAP), using the CBOR Object Signing and Encryption (COSE). OSCOAP 18 provides end-to-end encryption, integrity and replay protection to 19 CoAP payload, options, and header fields, as well as a secure message 20 binding. OSCOAP is designed for constrained nodes and networks and 21 can be used across intermediaries and over any layer. The use of 22 OSCOAP is signaled with the CoAP option Object-Security, also defined 23 in this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 14, 2017. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. The Object-Security Option . . . . . . . . . . . . . . . . . 5 62 3. The Security Context . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Security Context Definition . . . . . . . . . . . . . . . 6 64 3.2. Derivation of Security Context Parameters . . . . . . . . 8 65 3.3. Requirements on the Security Context Parameters . . . . . 10 66 4. Protected CoAP Message Fields . . . . . . . . . . . . . . . . 11 67 4.1. CoAP Payload . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. CoAP Header . . . . . . . . . . . . . . . . . . . . . . . 12 69 4.3. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 12 70 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 17 71 5.1. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 18 72 5.2. Additional Authenticated Data . . . . . . . . . . . . . . 19 73 6. Sequence Numbers, Replay, Message Binding, and Freshness . . 20 74 6.1. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 20 75 6.2. Replay Protection . . . . . . . . . . . . . . . . . . . . 20 76 6.3. Sequence Number and Replay Window State . . . . . . . . . 20 77 6.4. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 21 78 6.5. Delay and Mismatch Attacks . . . . . . . . . . . . . . . 21 79 7. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 22 80 7.1. Protecting the Request . . . . . . . . . . . . . . . . . 22 81 7.2. Verifying the Request . . . . . . . . . . . . . . . . . . 22 82 7.3. Protecting the Response . . . . . . . . . . . . . . . . . 23 83 7.4. Verifying the Response . . . . . . . . . . . . . . . . . 23 84 8. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 86 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 27 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 88 11.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 27 89 11.2. Media Type Registrations . . . . . . . . . . . . . . . . 27 90 11.3. CoAP Content Format Registration . . . . . . . . . . . . 28 91 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 94 13.2. Informative References . . . . . . . . . . . . . . . . . 30 95 Appendix A. OSCOAP Compression . . . . . . . . . . . . . . . . . 31 96 A.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 32 98 Appendix B. Test Vectors . . . . . . . . . . . . . . . . . . . . 33 99 Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 33 100 C.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 33 101 C.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 34 102 Appendix D. Object Security of Content (OSCON) . . . . . . . . . 36 103 D.1. Overhead OSCON . . . . . . . . . . . . . . . . . . . . . 37 104 D.2. MAC Only . . . . . . . . . . . . . . . . . . . . . . . . 38 105 D.3. Signature Only . . . . . . . . . . . . . . . . . . . . . 38 106 D.4. Authenticated Encryption with Additional Data (AEAD) . . 39 107 D.5. Symmetric Encryption with Asymmetric Signature (SEAS) . . 40 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 110 1. Introduction 112 The Constrained Application Protocol (CoAP) is a web application 113 protocol, designed for constrained nodes and networks [RFC7228]. 114 CoAP specifies the use of proxies for scalability and efficiency. At 115 the same time CoAP [RFC7252] references DTLS [RFC6347] for security. 116 Proxy operations on CoAP messages require DTLS to be terminated at 117 the proxy. The proxy therefore not only has access to the data 118 required for performing the intended proxy functionality, but is also 119 able to eavesdrop on, or manipulate any part of the CoAP payload and 120 metadata, in transit between client and server. The proxy can also 121 inject, delete, or reorder packages without being protected or 122 detected by DTLS. 124 This document defines Object Security of CoAP (OSCOAP), a data object 125 based security protocol, protecting CoAP message exchanges end-to- 126 end, across intermediary nodes. An analysis of end-to-end security 127 for CoAP messages through intermediary nodes is performed in 128 [I-D.hartke-core-e2e-security-reqs], this specification addresses the 129 forwarding case. In addition to the core features defined in 130 [RFC7252], OSCOAP supports Observe [RFC7641] and Blockwise [RFC7959]. 132 OSCOAP is designed for constrained nodes and networks and provides an 133 in-layer security protocol for CoAP which does not depend on 134 underlying layers. OSCOAP can be used anywhere that CoAP can be 135 used, including unreliable transport [RFC7228], reliable transport 136 [I-D.ietf-core-coap-tcp-tls], and non-IP transport 137 [I-D.bormann-6lo-coap-802-15-ie]. OSCOAP may also be used to protect 138 group communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The 139 use of OSCOAP does not affect the URI scheme and OSCOAP can therefore 140 be used with any URI scheme defined for CoAP. The application 141 decides the conditions for which OSCOAP is required. 143 OSCOAP builds on CBOR Object Signing and Encryption (COSE) 144 [I-D.ietf-cose-msg], providing end-to-end encryption, integrity, 145 replay protection, and secure message binding. The use of OSCOAP is 146 signaled with the CoAP option Object-Security, defined in Section 2. 147 OSCOAP provides protection of CoAP payload, certain options, and 148 header fields. The solution transforms an unprotected CoAP message 149 into a protected CoAP message in the following way: the unprotected 150 CoAP message is protected by including payload (if present), certain 151 options, and header fields in a COSE object. The message fields that 152 have been encrypted are removed from the message whereas the Object- 153 Security option and the COSE object are added, see Figure 1. 155 Client Server 156 | request: | 157 | GET example.com | 158 | [Header, Token, Options:{..., | 159 | Object-Security:COSE object}] | 160 +---------------------------------------------->| 161 | response: | 162 | 2.05 (Content) | 163 | [Header, Token, Options:{..., | 164 | Object-Security:-}, Payload:COSE object] | 165 |<----------------------------------------------+ 166 | | 168 Figure 1: Sketch of OSCOAP 170 OSCOAP may be used in extremely constrained settings, where CoAP over 171 DTLS may be prohibitive e.g. due to large code size. Alternatively, 172 OSCOAP can be combined with DTLS, thereby enabling end-to-end 173 security of e.g. CoAP payload and options, in combination with hop- 174 by-hop protection of the entire CoAP message, during transport 175 between end-point and intermediary node. Examples of the use of 176 OSCOAP are given in Appendix C. 178 The message protection provided by OSCOAP can alternatively be 179 applied only to the payload of individual messages. We call this 180 object security of content (OSCON) and it is defined in Appendix D. 182 1.1. Terminology 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in [RFC2119]. These 187 words may also appear in this document in lowercase, absent their 188 normative meanings. 190 Readers are expected to be familiar with the terms and concepts 191 described in CoAP [RFC7252], Observe [RFC7641], Blockwise [RFC7959], 192 COSE [I-D.ietf-cose-msg], CBOR [RFC7049], CDDL 194 [I-D.greevenbosch-appsawg-cbor-cddl], and constrained environments 195 [RFC7228]. 197 2. The Object-Security Option 199 The Object-Security option (see Figure 2) indicates that OSCOAP is 200 used to protect the CoAP message exchange. The Object-Security 201 option is critical, safe to forward, part of the cache key, not 202 repeatable, and opaque. 204 +-----+---+---+---+---+-----------------+--------+--------+ 205 | No. | C | U | N | R | Name | Format | Length | 206 +-----+---+---+---+---+-----------------+--------+--------| 207 | TBD | x | | | | Object-Security | opaque | 0- | 208 +-----+---+---+---+---+-----------------+--------+--------+ 209 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 211 Figure 2: The Object-Security Option 213 A successful response to a request with the Object-Security option 214 SHALL contain the Object-Security option. A CoAP endpoint SHOULD NOT 215 cache a response to a request with an Object-Security option, since 216 the response is only applicable to the original client's request. 217 The Object-Security option is included in the cache key for backward 218 compatibility with proxies not recognizing the Object-Security 219 option. The effect is that messages with the Object-Security option 220 will never generate cache hits. For Max-Age processing, see 221 Section 4.3.1.1. 223 The protection is achieved by means of a COSE object (see Section 5) 224 included in the protected CoAP message. The placement of the COSE 225 object depends on whether the method/response code allows payload 226 (see [RFC7252]): 228 o If the method/response code allows payload, then the compressed 229 COSE object is the payload of the protected message, and the 230 Object-Security option has length zero. An endpoint receiving a 231 CoAP message with payload, that also contains a non-empty Object- 232 Security option SHALL treat it as malformed and reject it. 234 o If the method/response code does not allow payload, then the 235 compressed COSE object is the value of the Object-Security option 236 and the length of the Object-Security option is equal to the size 237 of the compressed COSE object. An endpoint receiving a CoAP 238 message without payload, that also contains an empty Object- 239 Security option SHALL treat it as malformed and reject it. 241 The size of the COSE object depends on whether the method/response 242 code allows payload, if the message is a request or response, on the 243 set of options that are included in the unprotected message, the AEAD 244 algorithm, the length of the information identifying the security 245 context, and the length of the sequence number. 247 3. The Security Context 249 OSCOAP uses COSE with an Authenticated Encryption with Additional 250 Data (AEAD) algorithm between a CoAP client and a CoAP server. An 251 implementation supporting this specification MAY only implement the 252 client part or MAY only the server part. 254 The specification requires that client and server establish a 255 security context to apply to the COSE objects protecting the CoAP 256 messages. In this section we define the security context, and also 257 specify how to derive the initial security contexts in client and 258 server based on common shared secret and a key derivation function 259 (KDF). 261 3.1. Security Context Definition 263 The security context is the set of information elements necessary to 264 carry out the cryptographic operations in OSCOAP. For each endpoint, 265 the security context is composed of a "Common Context", a "Sender 266 Context", and a "Recipient Context". 268 The endpoints protect messages to send using the Sender Context and 269 verify messages received using the Recipient Context, both contexts 270 being derived from the Common Context and other data. Clients need 271 to be able to retrieve the correct security context to use. 273 An endpoint uses its Sender ID (SID) to derive its Sender Context, 274 and the other endpoint uses the same ID, now called Recipient ID 275 (RID), to derive its Recipient Context. In communication between two 276 endpoints, the Sender Context of one endpoint matches the Recipient 277 Context of the other endpoint, and vice versa. Thus the two security 278 contexts identified by the same IDs in the two endpoints are not the 279 same, but they are partly mirrored. Retrieval and use of the 280 security context are shown in Figure 3. 282 .------------. .------------. 283 | Common, | | Common, | 284 | Sender, | | Recipient,| 285 | Recipient | | Sender | 286 '------------' '------------' 287 Client Server 288 | | 289 Retrieve context for | request: | 290 target resource | [Token = Token1, | 291 Protect request with | kid = SID, ...] | 292 Sender Context +---------------------->| Retrieve context with 293 | | RID = SID 294 | | Verify request with 295 | | Recipient Context 296 | response: | Protect response with 297 | [Token = Token1, ...] | Sender Context 298 Retrieve context with |<----------------------+ 299 Token = Token1 | | 300 Verify request with | | 301 Recipient Context | | 303 Figure 3: Retrieval and use of the Security Context 305 The Common Context contains the following parameters: 307 o Algorithm (Alg). Value that identifies the COSE AEAD algorithm to 308 use for encryption. Its value is immutable once the security 309 context is established. 311 o Master Secret. Variable length, uniformly random byte string 312 containing the key used to derive traffic keys and IVs. Its value 313 is immutable once the security context is established. 315 o Master Salt (OPTIONAL). Variable length byte string containing 316 the salt used to derive traffic keys and IVs. Its value is 317 immutable once the security context is established. 319 The Sender Context contains the following parameters: 321 o Sender ID. Variable length byte string identifying the Sender 322 Context. Its value is immutable once the security context is 323 established. 325 o Sender Key. Byte string containing the symmetric key to protect 326 messages to send. Derived from Common Context and Sender ID. 327 Length is determined by Algorithm. Its value is immutable once 328 the security context is established. 330 o Sender IV. Byte string containing the IV to protect messages to 331 send. Derived from Common Context and Sender ID. Length is 332 determined by Algorithm. Its value is immutable once the security 333 context is established. 335 o Sequence Number. Non-negative integer used to protect requests 336 and observe responses to send. Used as partial IV 337 [I-D.ietf-cose-msg] to generate unique nonces for the AEAD. 338 Maximum value is determined by Algorithm. 340 The Recipient Context contains the following parameters: 342 o Recipient ID. Variable length byte string identifying the 343 Recipient Context. Its value is immutable once the security 344 context is established. 346 o Recipient Key. Byte string containing the symmetric key to verify 347 messages received. Derived from Common Context and Recipient ID. 348 Length is determined by the Algorithm. Its value is immutable 349 once the security context is established. 351 o Recipient IV. Byte string containing the IV to verify messages 352 received. Derived from Common Context and Recipient ID. Length 353 is determined by Algorithm. Its value is immutable once the 354 security context is established. 356 o Replay Window. The replay window to verify requests and observe 357 responses received. 359 An endpoint may free up memory by not storing the Sender Key, Sender 360 IV, Recipient Key, and Recipient IV, deriving them from the Common 361 Context when needed. Alternatively, an endpoint may free up memory 362 by not storing the Master Secret and Master Salt after the other 363 parameters have been derived. 365 The endpoints MAY interchange the client and server roles while 366 maintaining the same security context. When this happens, the former 367 server still protects messages to send using its Sender Context, and 368 verifies messages received using its Recipient Context. The same is 369 also true for the former client. The endpoints MUST NOT change the 370 Sender/Recipient ID. In other words, changing the roles does not 371 change the set of keys to be used. 373 3.2. Derivation of Security Context Parameters 375 The parameters in the security context are derived from a small set 376 of input parameters. The following input parameters SHALL be pre- 377 established: 379 o Master Secret 381 o Sender ID 383 o Recipient ID 385 The following input parameters MAY be pre-established. In case any 386 of these parameters is not pre-established, the default value 387 indicated below is used: 389 o AEAD Algorithm (Alg) 391 * Default is AES-CCM-64-64-128 (value 12) 393 o Master Salt 395 * Default is the empty string 397 o Key Derivation Function (KDF) 399 * Default is HKDF SHA-256 401 o Replay Window Type and Size 403 * Default is DTLS-type replay protection with a window size of 32 405 How the input parameters are pre-established, is application 406 specific. The EDHOC protocol [I-D.selander-ace-cose-ecdhe] enables 407 the establishment of input parameters with the property of forward 408 secrecy and negotiation of KDF and AEAD, it thus provides all 409 necessary pre-requisite steps for using OSCOAP as defined here. 411 3.2.1. Derivation of Sender Key/IV, Recipient Key/IV 413 The KDF MUST be one of the HKDF [RFC5869] algorithms defined in COSE. 414 HKDF SHA-256 is mandatory to implement. The security context 415 parameters Sender Key/IV and Recipient Key/IV SHALL be derived from 416 the input parameters using the HKDF, which consists of the 417 composition of the HKDF-Extract and HKDF-Expand steps ([RFC5869]): 419 output parameter = HKDF(salt, IKM, info, L) 421 where: 423 o salt is the Master Salt as defined above 425 o IKM is the Master Secret is defined above 426 o info is a CBOR array consisting of: 428 info = [ 429 id : bstr, 430 alg : int, 431 type : tstr, 432 L : int 433 ] 435 * id is the Sender ID or Recipient ID 437 * type is "Key" or "IV" 439 o L is the key/IV size of the AEAD algorithm in octets without 440 leading zeroes. 442 For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in 443 [I-D.ietf-cose-msg]) is used, the value for L is 16 for keys and 7 444 for IVs. 446 3.2.2. Initial Sequence Numbers and Replay Window 448 The Sequence Number is initialized to 0. The supported types of 449 replay protection and replay window length is application specific 450 and depends on the lower layers. Default is DTLS-type replay 451 protection with a window size of 32 initiated as described in 452 Section 4.1.2.6 of [RFC6347]. 454 3.3. Requirements on the Security Context Parameters 456 As collisions may lead to the loss of both confidentiality and 457 integrity, Sender ID SHALL be unique in the set of all security 458 contexts using the same Master Secret. Normally (e.g. when using 459 EDHOC) Sender IDs can be very short. Note that Sender IDs of 460 different lengths can be used with the same Master Secret. E.g. the 461 SID with value 0x00 is different from the SID with the value 0x0000. 462 If Sender ID uniqueness cannot be guaranteed, random Sender IDs MUST 463 be used. Random Sender IDs MUST be long enough so that the 464 probability of collisions is negligible. 466 To enable retrieval of the right Recipient Context, the Recipient ID 467 SHOULD be unique in the sets of all Recipient Contexts used by an 468 endpoint. 470 The same Master Salt MAY be used with several Master Secrets. 472 4. Protected CoAP Message Fields 474 OSCOAP transforms an unprotected CoAP message into a protected CoAP 475 message, and vice versa. This section defines how the CoAP message 476 fields are protected. OSCOAP protects as much of the unprotected 477 CoAP message as possible, while still allowing forward proxy 478 operations [I-D.hartke-core-e2e-security-reqs]. Message fields may 479 either be 481 o Class E: encrypted and integrity protected, 483 o Class I: integrity protected only, or 485 o Class U: unprotected. 487 This section also outlines how the message fields are transferred, a 488 detailed description of the processing is provided in Section 7. 489 Message fields of the unprotected CoAP message are either transferred 490 in the header/options part of the protected CoAP message, or in the 491 plaintext of the COSE object. Depending on which, the location of 492 the message field in the protected CoAP message is called "inner" or 493 "outer": 495 o Inner message field: message field included in the plaintext of 496 the COSE object of the protected CoAP message (see Section 5.1) 498 o Outer message field: message field included in the header or 499 options part of the protected CoAP message 501 The inner message fields are by definition encrypted and integrity 502 protected by the COSE object (Class E). The outer message fields are 503 not encrypted and thus visible to an intermediary, but may be 504 integrity protected by including the message field values in the AAD 505 of the COSE object (see Section 5.2). I.e. outer message fields may 506 be Class I or Class U. 508 Note that, even though the message formats are slightly different, 509 OSCOAP complies with CoAP over unreliable transport [RFC7252] as well 510 as CoAP over reliable transport [I-D.ietf-core-coap-tcp-tls]. 512 4.1. CoAP Payload 514 The CoAP Payload SHALL be encrypted and integrity protected (Class 515 E), and thus is an inner message field. 517 The sending endpoint writes the payload of the unprotected CoAP 518 message into the plaintext of the COSE object. 520 The receiving endpoint verifies and decrypts the COSE object, and 521 recreates the payload of the unprotected CoAP message. 523 4.2. CoAP Header 525 Many CoAP header fields are required to be read and changed during a 526 normal message exchange or when traversing a proxy and thus cannot be 527 protected between the endpoints, e.g. CoAP message layer fields such 528 as Message ID. 530 The CoAP header field Code MUST be sent in plaintext to support 531 RESTful processing, but MUST be integrity protected to prevent an 532 intermediary from changing, e.g. from GET to DELETE (Class I). The 533 CoAP version number MUST be integrity protected to prevent potential 534 future version-based attacks (Class I). Note that while the version 535 number is not sent in each CoAP message over reliable transport 536 [I-D.ietf-core-coap-tcp-tls], its value is known to client and 537 server. 539 Other CoAP header fields SHALL neither be integrity protected nor 540 encrypted (Class U). The CoAP header fields are thus outer message 541 fields. 543 The sending endpoint SHALL copy the header fields from the 544 unprotected CoAP message to the protected CoAP message. The 545 receiving endpoint SHALL copy the header fields from the protected 546 CoAP message to the unprotected CoAP message. Both sender and 547 receiver insert the CoAP version number and header field Code in the 548 AAD of the COSE object (see section Section 5.2). 550 4.3. CoAP Options 552 Most options are encrypted and integrity protected (Class E), and 553 thus inner message fields. But to allow certain proxy operations, 554 some options have outer values, i.e. are present in the protected 555 CoAP message. Certain options may have both an inner value and a 556 potentially different outer value, where the inner value is intended 557 for the destination endpoint and the outer value is intended for the 558 proxy. 560 A summary of how options are protected and processed is shown in 561 Figure 4. Options within each class are protected and processed in a 562 similar way, but certain options which require special processing as 563 described in the subsections and indicated by a * in Figure 4. 565 +----+----------------+---+---+---+ 566 | No.| Name | E | I | U | 567 +----+----------------+---+---+---+ 568 | 1 | If-Match | x | | | 569 | 3 | Uri-Host | | | x | 570 | 4 | ETag | x | | | 571 | 5 | If-None-Match | x | | | 572 | 6 | Observe | | * | | 573 | 7 | Uri-Port | | | x | 574 | 8 | Location-Path | x | | | 575 | 11 | Uri-Path | x | | | 576 | 12 | Content-Format | x | | | 577 | 14 | Max-Age | * | | | 578 | 15 | Uri-Query | x | | | 579 | 17 | Accept | x | | | 580 | 20 | Location-Query | x | | | 581 | 23 | Block2 | * | | | 582 | 27 | Block1 | * | | | 583 | 28 | Size2 | * | | | 584 | 35 | Proxy-Uri | | | * | 585 | 39 | Proxy-Scheme | | | x | 586 | 60 | Size1 | * | | | 587 +----+----------------+---+---+---+ 589 E=Encrypt and Integrity Protect, I=Integrity Protect only, 590 U=Unprotected, *=Special 592 Figure 4: Protection of CoAP Options 594 Unless specified otherwise, CoAP options not listed in Figure 4 SHALL 595 be encrypted and integrity protected and processed as class E 596 options. 598 Specifications of new CoAP options SHOULD define how they are 599 processed with OSCOAP. New COAP options SHOULD be of class E and 600 SHOULD NOT have outer options unless a forwarding proxy needs to read 601 that option value. If a certain option is both inner and outer, the 602 two values SHOULD NOT be the same, unless a proxy is required by 603 specification to be able to read the end-to-end value. 605 4.3.1. Class E Options 607 For options in class E (see Figure 4) the option value in the 608 unprotected CoAP message, if present, SHALL be encrypted and 609 integrity protected between the endpoints. Hence the actions 610 resulting from the use of such options is analogous to communicating 611 in a protected manner with the endpoint. For example, a client using 612 an ETag option will not be served by a proxy. 614 The sending endpoint SHALL write the class E option from the 615 unprotected CoAP message into the plaintext of the COSE object. 617 Except for the special options described in the subsections, the 618 sending endpoint SHALL NOT use the outer options of class E. 619 However, note that an intermediary may, legitimately or not, add, 620 change or remove the value of an outer option. 622 Except for the Block options Section 4.3.1.2, the receiving endpoint 623 SHALL discard any outer options of class E from the protected CoAP 624 message and SHALL replace it in the unprotected CoAP messages with 625 the value from the COSE object when present. 627 4.3.1.1. Max-Age 629 An inner Max-Age option, like other class E options, is used as 630 defined in [RFC7252] taking into account that it is not accessible to 631 proxies. 633 Since OSCOAP binds CoAP responses to requests, a cached response 634 would not be possible to use for any other request. To avoid 635 unnecessary caching, a server MAY add an outer Max-Age option with 636 value zero to protected CoAP responses (see Section 5.6.1 of 637 [RFC7252]). 639 The outer Max-Age option is not integrity protected. 641 4.3.1.2. The Block Options 643 Blockwise [RFC7959] is an optional feature. An implementation MAY 644 comply with [RFC7252] and the Object-Security option without 645 implementing [RFC7959]. 647 The Block options (Block1, Block2, Size1 and Size2) MAY be either 648 only inner options, only outer options or both inner and outer 649 options. The inner and outer options are processed independently. 651 The inner block options are used for endpoint-to-endpoint secure 652 fragmentation of payload into blocks and protection of information 653 about the fragmentation (block number, block size, last block). In 654 this case, the CoAP client fragments the CoAP message as defined in 655 [RFC7959] before the message is processed by OSCOAP. The CoAP server 656 first processes the OSCOAP message before processing blockwise as 657 defined in [RFC7959]. 659 There SHALL be a security policy defining a maximum unfragmented 660 message size for inner Block options such that messages exceeding 661 this size SHALL be fragmented by the sending endpoint. 663 Additionally, a proxy may arbitrarily do block fragmentation on any 664 CoAP message, in particular an OSCOAP message, as defined in 665 [RFC7959] and thereby add outer Block options to a block and send on 666 the next hop. The outer block options are thus neither encrypted nor 667 integrity protected. 669 An endpoint receiving a message with an outer Block option SHALL 670 first process this option according to [RFC7959], until all blocks of 671 the protected CoAP message has been received, or the cumulated 672 message size of the exceeds the maximum unfragmented message size. 673 In the latter case the message SHALL be discarded. In the former 674 case, the processing of the protected CoAP message continues as 675 defined in this document. 677 If the unprotected CoAP message in turn contains Block options, the 678 receiving endpoint processes this according to [RFC7959]. 680 TODO: Update processing to support multiple concurrently proceeding 681 requests 683 4.3.2. Class I Options 685 Except for the special options described in the subsections, for 686 options in Class I (see Figure 4) the option value SHALL only be 687 integrity protected between the endpoints. Options in Class I have 688 outer values. Unless otherwise specified, the sending endpoint SHALL 689 encode the Class I options in the protected CoAP message as described 690 in Section 4.3.4. 692 Class I options are included in the external_aad (Section 5.2). 694 4.3.2.1. Observe 696 Observe [RFC7641] is an optional feature. An implementation MAY 697 support [RFC7252] and the Object-Security option without supporting 698 [RFC7641]. The Observe option as used here targets the requirements 699 on forwarding of [I-D.hartke-core-e2e-security-reqs] 700 (Section 2.2.1.2). 702 In order for a proxy to support forwarding of Observe, there MUST be 703 an outer Observe option in the message. 705 o The Observe Registration (see Section 1.2 of [RFC7641]) of the 706 unprotected CoAP request SHALL be encoded in the protected CoAP 707 request as described in Section 4.3.4. 709 o The Observe Notification (see Section 1.2 of [RFC7641]) of the 710 unprotected CoAP response SHALL be encoded in the protected CoAP 711 response as described in Section 4.3.4. 713 To secure the Observe Registration and the order of the 714 Notifications, Observe SHALL be integrity protected as described in 715 this section: 717 o The Observe option in the unprotected CoAP request SHALL be 718 included in the external_aad of the request (see Section 5.2). 720 o The Observe option SHALL be included in the external_aad of the 721 response (see Section 5.2), with value set to the 3 least 722 significant bytes of the Sequence Number of the response 724 4.3.3. Class U Options 726 Options in Class U have outer values and are used to support forward 727 proxy operations. Unless otherwise specified, the sending endpoint 728 SHALL encode the Class U options in the protected CoAP message as 729 described in Section 4.3.4. 731 4.3.3.1. Uri-Host, Uri-Port, and Proxy-Scheme 733 The sending endpoint SHALL copy Uri-Host, Uri-Port, and Proxy-Scheme 734 from the unprotected CoAP message to the protected CoAP message. 735 When Uri-Host, Uri-Port, Proxy-Scheme options are present, Proxy-Uri 736 is not used [RFC7252]. 738 4.3.3.2. Proxy-Uri 740 Proxy-Uri, when present, is split by OSCOAP into class U options and 741 privacy sensitive class E options, which are processed accordingly. 742 When Proxy-Uri is used in the unprotected CoAP message, Uri-* are not 743 present [RFC7252]. 745 The sending endpoint SHALL first decompose the Proxy-Uri value of the 746 unprotected CoAP message into the Proxy-Scheme, Uri-Host, Uri-Port, 747 Uri-Path and Uri-Query options (if present) according to section 6.4 748 of [RFC7252]. 750 Uri-Path and Uri-Query are class E options and MUST be protected and 751 processed as if obtained from the unprotected CoAP message, see 752 Section 4.3.1. 754 The value of the Proxy-Uri option of the protected CoAP message MUST 755 be replaced with Proxy-Scheme, Uri-Host and Uri-Port options (if 756 present) composed according to section 6.5 of [RFC7252] and MUST be 757 processed as a class U option, see Section 4.3.3. 759 An example of how Proxy-Uri is processed is given below. 761 An unprotected CoAP message contains: 763 o Proxy-Uri = "coap://example.com/resource?q=1" 765 During OSCOAP processing, Proxy-Uri is split into: 767 o Proxy-Scheme = "coap" 769 o Uri-Host = "example.com" 771 o Uri-Port = "5863" 773 o Uri-Path = "resource" 775 o Uri-Query = "q=1" 777 Uri-Path and Uri-Query follow the processing defined in 778 Section 4.3.1. Proxy-Uri is added to the OSCOAP protected message 779 with value: 781 o Proxy-Uri = "coap://example.com" 783 4.3.4. Outer Options in the Protected CoAP Message 785 All options with outer values present in the protected CoAP message, 786 including the Object-Security option, SHALL be encoded as described 787 in Section 3.1 of [RFC7252], where the delta is the difference to the 788 previously included outer option. 790 5. The COSE Object 792 This section defines how to use COSE [I-D.ietf-cose-msg] to wrap and 793 protect data in the unprotected CoAP message. OSCOAP uses the 794 untagged COSE_Encrypt0 structure with an Authenticated Encryption 795 with Additional Data (AEAD) algorithm. The key lengths, IV lengths, 796 and maximum sequence number are algorithm dependent. 798 The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of 799 [I-D.ietf-cose-msg] is mandatory to implement. For AES-CCM-64-64-128 800 the length of Sender Key and Recipient Key is 128 bits, the length of 801 nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum 802 Sequence Number is 2^55 - 1. 804 The nonce is constructed as described in Section 3.1 of 805 [I-D.ietf-cose-msg], i.e. by padding the partial IV (Sequence Number 806 in network byte order) with zeroes and XORing it with the context IV 807 (Sender IV or Recipient IV). The first bit in the Sender IV or 808 Recipient IV SHALL be flipped in responses. 810 We denote by Plaintext the data that is encrypted and integrity 811 protected, and by Additional Authenticated Data (AAD) the data that 812 is integrity protected only. 814 The COSE Object SHALL be a COSE_Encrypt0 object with fields defined 815 as follows 817 o The "protected" field includes: 819 * The "Partial IV" parameter. The value is set to the Sequence 820 Number. The Partial IV SHALL be of minimum length needed to 821 encode the sequence number. This parameter SHALL be present in 822 requests, and MAY be present in responses. In case of Observe 823 (Section 4.3.2.1}) the Partial IV SHALL be present in the 824 response. 826 * The "kid" parameter. The value is set to the Sender ID (see 827 Section 3). This parameter SHALL be present in requests and 828 SHALL NOT be present in responses. 830 o The "unprotected" field is empty. 832 o The "ciphertext" field is computed from the Plaintext (see 833 Section 5.1) and the Additional Authenticated Data (AAD) (see 834 Section 5.2) following Section 5.2 of [I-D.ietf-cose-msg]. 836 The encryption process is described in Section 5.3 of 837 [I-D.ietf-cose-msg]. 839 5.1. Plaintext 841 The Plaintext is formatted as a CoAP message without Header (see 842 Figure 5) consisting of: 844 o all Class E options Section 4.3.1 present in the unprotected CoAP 845 message (see Section 4). The options are encoded as described in 846 Section 3.1 of [RFC7252], where the delta is the difference to the 847 previously included Class E option; and 849 o the Payload of unprotected CoAP message, if present, and in that 850 case prefixed by the one-byte Payload Marker (0xFF). 852 0 1 2 3 853 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Options to Encrypt (if any) ... 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |1 1 1 1 1 1 1 1| Payload (if any) ... 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 (only if there 860 is payload) 862 Figure 5: Plaintext 864 5.2. Additional Authenticated Data 866 The external_aad SHALL be a CBOR array as defined below: 868 external_aad = [ 869 ver : uint, 870 code : uint, 871 options : bstr, 872 alg : int, 873 request_kid : bstr, 874 request_seq : bstr 875 ] 877 where: 879 o ver: contains the CoAP version number, as defined in Section 3 of 880 [RFC7252]. 882 o code: contains is the CoAP Code of the unprotected CoAP message, 883 as defined in Section 3 of [RFC7252]. 885 o options: contains the Class I options Section 4.3.2 present in the 886 unprotected CoAP message encoded as described in Section 3.1 of 887 [RFC7252], where the delta is the difference to the previously 888 included class I option 890 o alg: contains the Algorithm from the security context used for the 891 exchange (see Section 3.1). 893 o request_kid: contains the value of the 'kid' in the COSE object of 894 the request (see Section 5). 896 o request_seq: contains the value of the 'Partial IV' in the COSE 897 object of the request (see Section 5). 899 6. Sequence Numbers, Replay, Message Binding, and Freshness 901 6.1. AEAD Nonce Uniqueness 903 An AEAD nonce MUST NOT be used more than once per AEAD key. In order 904 to assure unique nonces, each Sender Context contains a Sequence 905 Number used to protect requests, and - in case of Observe - 906 responses. The maximum sequence number is algorithm dependent and 907 SHALL be 2^(min(nonce length in bits, 56) - 1) - 1. If the Sequence 908 Number exceeds the maximum sequence number, the endpoint MUST NOT 909 process any more messages with the given Sender Context. The 910 endpoint SHOULD acquire a new security context (and consequently 911 inform the other endpoint) before this happens. The latter is out of 912 scope of this document. 914 6.2. Replay Protection 916 In order to protect from replay of messages, each Recipient Context 917 contains a Replay Window used to verify request, and - in case of 918 Observe - responses. A receiving endpoint SHALL verify that a 919 Sequence Number (Partial IV) received in the COSE object has not been 920 received before in the Recipient Context. The size and type of the 921 Replay Window depends on the use case and lower protocol layers. In 922 case of reliable and ordered transport from endpoint to endpoint, the 923 recipient MAY just store the last received sequence number and 924 require that newly received Sequence Numbers equals the last received 925 Sequence Number + 1. 927 6.3. Sequence Number and Replay Window State 929 6.3.1. The Basic Case 931 To prevent reuse of the Nonce/Sequence Number with the same key, or 932 from accepting replayed messages, a node needs to handle the 933 situation of suddenly losing sequence number and replay window state 934 in RAM, e.g. as a result of a reboot. 936 After boot, a node MAY reject to use existing security contexts from 937 before it booted and MAY establish a new security context with each 938 party it communicates, e.g. using EDHOC 939 [I-D.selander-ace-cose-ecdhe]. However, establishing a fresh 940 security context may have a non-negligible cost in terms of e.g. 941 power consumption. 943 If a stored security context is to be used after reboot, then the 944 node MUST NOT reuse a previous Sequence Number and MUST NOT accept 945 previously accepted messages. The node MAY perform the following 946 procedure: 948 o Before sending a message, the client stores in persistent memory a 949 sequence number associated to the stored security context higher 950 than any sequence number which has been or are being sent using 951 this security context. After boot, the client does not use any 952 lower sequence number in a request than what was persistently 953 stored with that security context. 955 * Storing to persistent memory can be costly. Instead of storing 956 a sequence number for each request, the client may store Seq + 957 K to persistent memory every K requests, where Seq is the 958 current sequence number and K > 1. This is a trade-off between 959 the number of storage operations and efficient use of sequence 960 numbers. 962 o After boot, before accepting a message from a stored security 963 context, the server synchronizes the replay window so that no old 964 messages are being accepted. The server uses the Repeat option 965 [I-D.mattsson-core-coap-actuators] for synchronizing the replay 966 window: For each stored security context, the first time after 967 boot the server receives an OSCOAP request, it generates a pseudo- 968 random nonce and responds with the Repeat option set to the nonce 969 as described in [I-D.mattsson-core-coap-actuators]. If the server 970 receives a repeated OSCOAP request containing the Repeat option 971 and the same nonce, and if the server can verify the request, then 972 the sequence number obtained in the repeated message is set as the 973 lower limit of the replay window. 975 6.4. Freshness 977 For responses without Observe, OSCOAP provides absolute freshness. 978 For requests, and responses with Observe, OSCOAP provides relative 979 freshness in the sense that the sequence numbers allows a recipient 980 to determine the relative order of messages. For applications having 981 stronger demands on freshness (e.g. control of actuators), OSCOAP 982 needs to be augmented with mechanisms providing absolute freshness 983 [I-D.mattsson-core-coap-actuators]. 985 6.5. Delay and Mismatch Attacks 987 In order to prevent response delay and mismatch attacks 988 [I-D.mattsson-core-coap-actuators] from on-path attackers and 989 compromised proxies, OSCOAP binds responses to the request by 990 including the request's ID (Sender ID or Recipient ID) and sequence 991 number in the AAD of the response. The server therefore needs to 992 store the request's ID (Sender ID or Recipient ID) and sequence 993 number until all responses have been sent. 995 7. Processing 997 7.1. Protecting the Request 999 Given an unprotected request, the client SHALL perform the following 1000 steps to create a protected request: 1002 1. Retrieve the Sender Context associated with the target resource. 1004 2. Compose the Additional Authenticated Data, as described in 1005 Section 5. 1007 3. Compose the AEAD nonce by XORing the context IV (Sender IV) with 1008 the partial IV (Sequence Number in network byte order). 1009 Increment the Sequence Number by one. 1011 4. Encrypt the COSE object using the Sender Key. Compress the COSE 1012 Object as specified in Appendix A. 1014 5. Format the protected CoAP message according to Section 4. The 1015 Object-Security option is added, see Section 4.3.4. 1017 6. Store the association Token - Security Context. The client SHALL 1018 be able to find the Recipient Context from the Token in the 1019 response. 1021 7.2. Verifying the Request 1023 A server receiving a request containing the Object-Security option 1024 SHALL perform the following steps: 1026 1. Process outer Block options according to [RFC7959], until all 1027 blocks of the request have been received, see Section 4.3.1.2. 1029 2. Retrieve the Recipient Context associated with the Recipient ID 1030 in the 'kid' parameter of the COSE object. 1032 3. Verify the Sequence Number in the 'Partial IV' parameter, as 1033 described in Section 6. 1035 4. Compose the Additional Authenticated Data, as described in 1036 Section 5. 1038 5. Compose the AEAD nonce by XORing the context IV (Recipient IV) 1039 with the padded 'Partial IV' parameter, received in the COSE 1040 Object. 1042 6. Decrypt the COSE object using the Recipient Key. 1044 * If decryption fails, the server MUST stop processing the 1045 request and SHOULD send an 4.01 error message. 1047 * If decryption succeeds, update the Recipient Replay Window, as 1048 described in Section 6. 1050 7. Add decrypted options or payload to the unprotected request, 1051 overwriting any outer E options (see Section 4). The Object- 1052 Security option is removed. 1054 8. The unprotected CoAP request is processed according to [RFC7252] 1056 7.3. Protecting the Response 1058 Given an unprotected response, the server SHALL perform the following 1059 steps to create a protected response: 1061 1. Retrieve the Sender Context in the Security Context used to 1062 verify the request. 1064 2. Compose the Additional Authenticated Data, as described in 1065 Section 5. 1067 3. Compose the AEAD nonce 1069 * If Observe is not used, compose the AEAD nonce by XORing the 1070 context IV (Recipient IV with the first bit flipped) with the 1071 padded Partial IV parameter from the request. 1073 * If Observe is used, compose the AEAD nonce by XORing the 1074 context IV (Recipient IV with the first bit flipped) with the 1075 partial IV (Sequence Number in network byte order). Increment 1076 the Sequence Number by one. 1078 4. Encrypt the COSE object using the Sender Key. Compress the COSE 1079 Object as specified in Appendix A. 1081 5. Format the protected CoAP message according to Section 4. The 1082 Object-Security option is added, see Section 4.3.4. 1084 7.4. Verifying the Response 1086 A client receiving a response containing the Object-Security option 1087 SHALL perform the following steps: 1089 1. Process outer Block options according to [RFC7959], until all 1090 blocks of the protected CoAP message have been received, see 1091 Section 4.3.1.2. 1093 2. Retrieve the Recipient Context associated with the Token. 1095 3. If Observe is used, verify the Sequence Number in the 'Partial 1096 IV' parameter as described in Section 6. 1098 4. Compose the Additional Authenticated Data, as described in 1099 Section 5. 1101 5. Compose the AEAD nonce 1103 * If Observe is not used, compose the AEAD nonce by XORing the 1104 context IV (Recipient IV with the first bit flipped) with the 1105 padded Partial IV parameter from the request. 1107 * If Observe is used, compose the AEAD nonce by XORing the 1108 context IV (Recipient IV with the first bit flipped) with the 1109 padded Partial IV parameter from the response. 1111 6. Decrypt the COSE object using the Recipient Key. 1113 * If decryption fails, the client MUST stop processing the 1114 response and SHOULD send an 4.01 error message. 1116 * If decryption succeeds and Observe is used, update the 1117 Recipient Replay Window, as described in Section 6. 1119 7. Add decrypted options or payload to the unprotected response 1120 overwriting any outer E options (see Section 4). The Object- 1121 Security option is removed. 1123 * If Observe is used, replace the Observe value with the 3 least 1124 significant bytes in the sequence number. 1126 8. The unprotected CoAP response is processed according to [RFC7252] 1128 8. Web Linking 1130 The use of OSCOAP MAY be indicated by a target attribute "osc" in a 1131 web link [RFC5988] to a CoAP resource. This attribute is a hint 1132 indicating that the destination of that link is to be accessed using 1133 OSCOAP. Note that this is simply a hint, it does not include any 1134 security context material or any other information required to run 1135 OSCOAP. 1137 A value MUST NOT be given for the "osc" attribute; any present value 1138 MUST be ignored by parsers. The "osc" attribute MUST NOT appear more 1139 than once in a given link-value; occurrences after the first MUST be 1140 ignored by parsers. 1142 9. Security Considerations 1144 In scenarios with intermediary nodes such as proxies or brokers, 1145 transport layer security such as DTLS only protects data hop-by-hop. 1146 As a consequence the intermediary nodes can read and modify 1147 information. The trust model where all intermediate nodes are 1148 considered trustworthy is problematic, not only from a privacy 1149 perspective, but also from a security perspective, as the 1150 intermediaries are free to delete resources on sensors and falsify 1151 commands to actuators (such as "unlock door", "start fire alarm", 1152 "raise bridge"). Even in the rare cases, where all the owners of the 1153 intermediary nodes are fully trusted, attacks and data breaches make 1154 such an architecture brittle. 1156 DTLS protects hop-by-hop the entire CoAP message, including header, 1157 options, and payload. OSCOAP protects end-to-end the payload, and 1158 all information in the options and header, that is not required for 1159 forwarding (see Section 4). DTLS and OSCOAP can be combined, thereby 1160 enabling end-to-end security of CoAP payload, in combination with 1161 hop-by-hop protection of the entire CoAP message, during transport 1162 between end-point and intermediary node. 1164 The CoAP message layer, however, cannot be protected end-to-end 1165 through intermediary devices since the parameters Type and Message 1166 ID, as well as Token and Token Length may be changed by a proxy. 1167 Moreover, messages that are not possible to verify should for 1168 security reasons not always be acknowledged but in some cases be 1169 silently dropped. This would not comply with CoAP message layer, but 1170 does not have an impact on the application layer security solution, 1171 since message layer is excluded from that. 1173 The use of COSE to protect CoAP messages as specified in this 1174 document requires an established security context. The method to 1175 establish the security context described in Section 3.2 is based on a 1176 common shared secret material in client and server, which may be 1177 obtained e.g. by using EDHOC [I-D.selander-ace-cose-ecdhe] or the ACE 1178 framework [I-D.ietf-ace-oauth-authz]. An OSCOAP profile of ACE is 1179 described in [I-D.seitz-ace-oscoap-profile]. 1181 The formula 2^(min(nonce length in bits, 56) - 1) - 1 (Section 6.1) 1182 guarantees unique nonces during the required use the algorithm, 1183 considering the same partial IV and flipped first bit of IV 1184 (Section 5) is used in request and response (which is the reason for 1185 -1 in the exponent). The compression algorithm (Appendix A) assumes 1186 that the partial IV is 56 bits or less (which is the reason for 1187 min(,) in the exponent). 1189 The mandatory-to-implement AEAD algorithm AES-CCM-64-64-128 is 1190 selected for broad applicability in terms of message size (2^64 1191 blocks) and maximum number of messages (2^56). Compatibility with 1192 CCM* is achieved by using the algorithm AES-CCM-16-64-128 1193 [I-D.ietf-cose-msg]. 1195 Most AEAD algorithms require a unique nonce for each message, for 1196 which the sequence numbers in the COSE message field "Partial IV" is 1197 used. If the recipient accepts any sequence number larger than the 1198 one previously received, then the problem of sequence number 1199 synchronization is avoided. With reliable transport it may be 1200 defined that only messages with sequence number which are equal to 1201 previous sequence number + 1 are accepted. The alternatives to 1202 sequence numbers have their issues: very constrained devices may not 1203 be able to support accurate time, or to generate and store large 1204 numbers of random nonces. The requirement to change key at counter 1205 wrap is a complication, but it also forces the user of this 1206 specification to think about implementing key renewal. 1208 The inner block options enable the sender to split large messages 1209 into protected blocks such that the receiving node can verify blocks 1210 before having received the complete message. The outer block options 1211 allow for arbitrary proxy fragmentation operations that cannot be 1212 verified by the endpoints, but can by policy be restricted in size 1213 since the encrypted options allow for secure fragmentation of very 1214 large messages. A maximum message size (above which the sending 1215 endpoint fragments the message and the receiving endpoint discards 1216 the message, if complying to the policy) may be obtained as part of 1217 normal resource discovery. 1219 Applications need to use a padding scheme if the content of a message 1220 can be determined solely from the length of the payload. As an 1221 example, the strings "YES" and "NO" even if encrypted can be 1222 distinguished from each other as there is no padding supplied by the 1223 current set of encryption algorithms. Some information can be 1224 determined even from looking at boundary conditions. An example of 1225 this would be returning an integer between 0 and 100 where lengths of 1226 1, 2 and 3 will provide information about where in the range things 1227 are. Three different methods to deal with this are: 1) ensure that 1228 all messages are the same length. For example using 0 and 1 instead 1229 of 'yes' and 'no'. 2) Use a character which is not part of the 1230 responses to pad to a fixed length. For example, pad with a space to 1231 three characters. 3) Use the PKCS #7 style padding scheme where m 1232 bytes are appended each having the value of m. For example, 1233 appending a 0 to "YES" and two 1's to "NO". This style of padding 1234 means that all values need to be padded. 1236 10. Privacy Considerations 1238 Privacy threats executed through intermediate nodes are considerably 1239 reduced by means of OSCOAP. End-to-end integrity protection and 1240 encryption of CoAP payload and all options that are not used for 1241 forwarding, provide mitigation against attacks on sensor and actuator 1242 communication, which may have a direct impact on the personal sphere. 1244 The unprotected options (Figure 4) may reveal privacy sensitive 1245 information. In particular Uri-Host SHOULD NOT contain privacy 1246 sensitive information. 1248 CoAP headers sent in plaintext allow for example matching of CON and 1249 ACK (CoAP Message Identifier), matching of request and responses 1250 (Token) and traffic analysis. 1252 11. IANA Considerations 1254 Note to RFC Editor: Please replace all occurrences of "[[this 1255 document]]" with the RFC number of this specification. 1257 11.1. CoAP Option Numbers Registry 1259 The Object-Security option is added to the CoAP Option Numbers 1260 registry: 1262 +--------+-----------------+-------------------+ 1263 | Number | Name | Reference | 1264 +--------+-----------------+-------------------+ 1265 | TBD | Object-Security | [[this document]] | 1266 +--------+-----------------+-------------------+ 1268 11.2. Media Type Registrations 1270 The "application/oscon" media type is added to the Media Types 1271 registry: 1273 Type name: application 1275 Subtype name: oscon 1277 Required parameters: N/A 1279 Optional parameters: N/A 1281 Encoding considerations: binary 1283 Security considerations: See Appendix C of this document. 1285 Interoperability considerations: N/A 1287 Published specification: [[this document]] (this document) 1289 Applications that use this media type: To be identified 1291 Fragment identifier considerations: N/A 1293 Additional information: 1295 * Magic number(s): N/A 1297 * File extension(s): N/A 1299 * Macintosh file type code(s): N/A 1301 Person & email address to contact for further information: 1302 Goeran Selander 1304 Intended usage: COMMON 1306 Restrictions on usage: N/A 1308 Author: Goeran Selander, goran.selander@ericsson.com 1310 11.3. CoAP Content Format Registration 1312 The "application/oscon" content format is added to the CoAP Content 1313 Format registry: 1315 +-------------------+----------+----+-------------------+ 1316 | Media type | Encoding | ID | Reference | 1317 +-------------------+----------+----+-------------------+ 1318 | application/oscon | - | 70 | [[this document]] | 1319 +-------------------+----------+----+-------------------+ 1321 12. Acknowledgments 1323 The following individuals provided input to this document: Christian 1324 Amsuess, Carsten Bormann, Joakim Brorsson, Martin Gunnarsson, Klaus 1325 Hartke, Jim Schaad, Marco Tiloca, and Malisa Vučinić. 1327 Ludwig Seitz and Goeran Selander worked on this document as part of 1328 the CelticPlus project CyberWI, with funding from Vinnova. 1330 13. References 1332 13.1. Normative References 1334 [I-D.ietf-cose-msg] 1335 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1336 draft-ietf-cose-msg-24 (work in progress), November 2016. 1338 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1339 Requirement Levels", BCP 14, RFC 2119, 1340 DOI 10.17487/RFC2119, March 1997, 1341 . 1343 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1344 Key Derivation Function (HKDF)", RFC 5869, 1345 DOI 10.17487/RFC5869, May 2010, 1346 . 1348 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 1349 DOI 10.17487/RFC5988, October 2010, 1350 . 1352 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1353 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1354 January 2012, . 1356 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1357 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1358 October 2013, . 1360 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1361 Application Protocol (CoAP)", RFC 7252, 1362 DOI 10.17487/RFC7252, June 2014, 1363 . 1365 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1366 Application Protocol (CoAP)", RFC 7641, 1367 DOI 10.17487/RFC7641, September 2015, 1368 . 1370 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1371 the Constrained Application Protocol (CoAP)", RFC 7959, 1372 DOI 10.17487/RFC7959, August 2016, 1373 . 1375 13.2. Informative References 1377 [I-D.bormann-6lo-coap-802-15-ie] 1378 Bormann, C., "Constrained Application Protocol (CoAP) over 1379 IEEE 802.15.4 Information Element for IETF", draft- 1380 bormann-6lo-coap-802-15-ie-00 (work in progress), April 1381 2016. 1383 [I-D.greevenbosch-appsawg-cbor-cddl] 1384 Vigano, C. and H. Birkholz, "CBOR data definition language 1385 (CDDL): a notational convention to express CBOR data 1386 structures", draft-greevenbosch-appsawg-cbor-cddl-09 (work 1387 in progress), September 2016. 1389 [I-D.hartke-core-e2e-security-reqs] 1390 Selander, G., Palombini, F., and K. Hartke, "Requirements 1391 for CoAP End-To-End Security", draft-hartke-core-e2e- 1392 security-reqs-02 (work in progress), January 2017. 1394 [I-D.ietf-ace-oauth-authz] 1395 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1396 H. Tschofenig, "Authentication and Authorization for 1397 Constrained Environments (ACE)", draft-ietf-ace-oauth- 1398 authz-05 (work in progress), February 2017. 1400 [I-D.ietf-core-coap-tcp-tls] 1401 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1402 Silverajan, B., and B. Raymor, "CoAP (Constrained 1403 Application Protocol) over TCP, TLS, and WebSockets", 1404 draft-ietf-core-coap-tcp-tls-07 (work in progress), March 1405 2017. 1407 [I-D.mattsson-core-coap-actuators] 1408 Mattsson, J., Fornehed, J., Selander, G., and F. 1409 Palombini, "Controlling Actuators with CoAP", draft- 1410 mattsson-core-coap-actuators-02 (work in progress), 1411 November 2016. 1413 [I-D.seitz-ace-oscoap-profile] 1414 Seitz, L. and F. Palombini, "OSCOAP profile of ACE", 1415 draft-seitz-ace-oscoap-profile-01 (work in progress), 1416 October 2016. 1418 [I-D.selander-ace-cose-ecdhe] 1419 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1420 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1421 cose-ecdhe-04 (work in progress), October 2016. 1423 [I-D.tiloca-core-multicast-oscoap] 1424 Tiloca, M., Selander, G., and F. Palombini, "Secure group 1425 communication for CoAP", draft-tiloca-core-multicast- 1426 oscoap-00 (work in progress), October 2016. 1428 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1429 Constrained-Node Networks", RFC 7228, 1430 DOI 10.17487/RFC7228, May 2014, 1431 . 1433 Appendix A. OSCOAP Compression 1435 The Concise Binary Object Representation (CBOR) combines very small 1436 message sizes with extensibility. CBOR Object Signing and Encryption 1437 (COSE) uses CBOR to achieve smaller message sizes than JOSE. COSE is 1438 however constructed to support a large number of different stateless 1439 use cases, and is not fully optimized for use as a stateful security 1440 protocol, leading to a larger than necessary message expansion. In 1441 this section we define a simple stateless compression mechanism for 1442 OSCOAP, which significantly reduces the per-packet overhead. 1444 The value of the Object-Security option SHALL in general be encoded 1445 as: 1447 [ 1448 Partial IV, 1449 ? kid, 1450 ciphertext 1451 ] 1453 Furthermore, the type and length for the ciphertext is redundant and 1454 10 bits in the first two bytes are static. The type and length for 1455 the ciphertext SHALL be excluded, and the first sixteen bits in the 1456 above COSE array SHALL be encoded as a single byte: 1458 10000abc 01000def -> 00abcdef 1460 The exception is Responses without Observe that SHALL be encoded as: 1462 ciphertext 1464 A.1. Examples 1466 A.1.1. Example Request 1468 COSE Object Before Compression (24 bytes) 1469 83 a2 04 41 25 06 41 05 a0 4e ae a0 15 56 67 92 1470 4d ff 8a 24 e4 cb 35 b9 1472 [ 1473 { 1474 4:h'25', 1475 6:h'05' 1476 }, 1477 {}, 1478 h'aea0155667924dff8a24e4cb35b9' 1479 ] 1481 After Compression (18 bytes) 1482 19 05 41 25 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 1483 35 b9 1485 A.1.2. Example Response 1487 COSE Object Before Compression (18 bytes) 1488 83 a0 a0 4e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 1489 35 b9 1491 [ 1492 {}, 1493 {}, 1494 h'aea0155667924dff8a24e4cb35b9' 1495 ] 1497 After Compression (14 bytes) 1498 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 1500 A.1.3. Example Response (with Observe) 1501 COSE Object Before Compression (21 bytes) 1502 83 a1 06 41 07 a0 4e ae a0 15 56 67 92 4d ff 8a 1503 24 e4 cb 35 b9 1505 [ 1506 { 1507 6:h'07' 1508 }, 1509 {}, 1510 h'aea0155667924dff8a24e4cb35b9' 1511 ] 1513 After Compression (16 bytes) 1514 11 07 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 1516 Appendix B. Test Vectors 1518 TODO: This section needs to be updated. 1520 Appendix C. Examples 1522 This section gives examples of OSCOAP. The message exchanges are 1523 made, based on the assumption that there is a security context 1524 established between client and server. For simplicity, these 1525 examples only indicate the content of the messages without going into 1526 detail of the COSE message format. 1528 C.1. Secure Access to Sensor 1530 This example targets the scenario in Section 3.1 of 1531 [I-D.hartke-core-e2e-security-reqs] and illustrates a client 1532 requesting the alarm status from a server. 1534 Client Proxy Server 1535 | | | 1536 +----->| | Code: 0.01 (GET) 1537 | GET | | Token: 0x8c 1538 | | | Object-Security: [kid:5f, seq:42, 1539 | | | {Uri-Path:"alarm_status"}] 1540 | | | Payload: - 1541 | | | 1542 | +----->| Code: 0.01 (GET) 1543 | | GET | Token: 0x7b 1544 | | | Object-Security: [kid:5f, seq:42, 1545 | | | {Uri-Path:"alarm_status"}] 1546 | | | Payload: - 1547 | | | 1548 | |<-----+ Code: 2.05 (Content) 1549 | | 2.05 | Token: 0x7b 1550 | | | Object-Security: - 1551 | | | Payload: [{"OFF"}] 1552 | | | 1553 |<-----+ | Code: 2.05 (Content) 1554 | 2.05 | | Token: 0x8c 1555 | | | Object-Security: - 1556 | | | Payload: [{"OFF"}] 1557 | | | 1559 Figure 6: Secure Access to Sensor. Square brackets [ ... ] indicate 1560 a COSE object. Curly brackets { ... } indicate encrypted data. 1562 Since the method (GET) doesn't allow payload, the Object-Security 1563 option carries the COSE object as its value. Since the response code 1564 (Content) allows payload, the COSE object is carried as the CoAP 1565 payload. 1567 The COSE header of the request contains an identifier (5f), 1568 indicating which security context was used to protect the message and 1569 a sequence number (42). The option Uri-Path ("alarm_status") and 1570 payload ("OFF") are encrypted. 1572 The server verifies that the sequence number has not been received 1573 before. The client verifies that the response is bound to the 1574 request. 1576 C.2. Secure Subscribe to Sensor 1578 This example targets the scenario in Section 3.2 of 1579 [I-D.hartke-core-e2e-security-reqs] and illustrates a client 1580 requesting subscription to a blood sugar measurement resource (GET 1581 /glucose), first receiving the value 220 mg/dl and then a second 1582 value 180 mg/dl. 1584 Client Proxy Server 1585 | | | 1586 +----->| | Code: 0.01 (GET) 1587 | GET | | Token: 0x83 1588 | | | Observe: 0 1589 | | | Object-Security: [kid:ca, seq:15, 1590 | | | {Uri-Path:"glucose"}] 1591 | | | Payload: - 1592 | | | 1593 | +----->| Code: 0.01 (GET) 1594 | | GET | Token: 0xbe 1595 | | | Observe: 0 1596 | | | Object-Security: [kid:ca, seq:15, 1597 | | | {Uri-Path:"glucose"}] 1598 | | | Payload: - 1599 | | | 1600 | |<-----+ Code: 2.05 (Content) 1601 | | 2.05 | Token: 0xbe 1602 | | | Observe: 000032 1603 | | | Object-Security: - 1604 | | | Payload: [seq:32, {Content-Format:0, "220"}] 1605 | | | 1606 |<-----+ | Code: 2.05 (Content) 1607 | 2.05 | | Token: 0x83 1608 | | | Observe: 000032 1609 | | | Object-Security: - 1610 | | | Payload: [seq:32, {Content-Format:0, "220"}] 1611 ... ... ... 1612 | | | 1613 | |<-----+ Code: 2.05 (Content) 1614 | | 2.05 | Token: 0xbe 1615 | | | Observe: 000036 1616 | | | Object-Security: - 1617 | | | Payload: [seq:36, {Content-Format:0, "180"}] 1618 | | | 1619 |<-----+ | Code: 2.05 (Content) 1620 | 2.05 | | Token: 0x83 1621 | | | Observe: 000036 1622 | | | Object-Security: - 1623 | | | Payload: [seq:36, {Content-Format:0, "180"}] 1624 | | | 1626 Figure 7: Secure Subscribe to Sensor. Square brackets [ ... ] 1627 indicate a COSE object. Curly brackets { ... } indicate encrypted 1628 data. 1630 Since the method (GET) doesn't allow payload, the Object-Security 1631 option carries the COSE object as its value. Since the response code 1632 (Content) allows payload, the COSE object is carried as the CoAP 1633 payload. 1635 The COSE header of the request contains an identifier (ca), 1636 indicating the security context used to protect the message and a 1637 Sequence Number (15). The COSE header of the responses contains 1638 sequence numbers (32 and 36). The options Content-Format (0) and the 1639 payload ("220" and "180"), are encrypted. The Observe option is 1640 integrity protected. The shown Observe values (000032 and 000036) 1641 are the ones that the client will see after OSCOAP processing. 1643 The server verifies that the sequence number has not been received 1644 before. The client verifies that the sequence number has not been 1645 received before and that the responses are bound to the request. 1647 Appendix D. Object Security of Content (OSCON) 1649 TODO: This section needs to be updated. 1651 OSCOAP protects message exchanges end-to-end between a certain client 1652 and a certain server, targeting the security requirements for forward 1653 proxy of [I-D.hartke-core-e2e-security-reqs]. In contrast, many use 1654 cases require one and the same message to be protected for, and 1655 verified by, multiple endpoints, see caching proxy section of 1656 [I-D.hartke-core-e2e-security-reqs]. Those security requirements can 1657 be addressed by protecting essentially the payload/content of 1658 individual messages using the COSE format ([I-D.ietf-cose-msg]), 1659 rather than the entire request/response message exchange. This is 1660 referred to as Object Security of Content (OSCON). 1662 OSCON transforms an unprotected CoAP message into a protected CoAP 1663 message in the following way: the payload of the unprotected CoAP 1664 message is wrapped by a COSE object, which replaces the payload of 1665 the unprotected CoAP message. We call the result the "protected" 1666 CoAP message. 1668 The unprotected payload shall be the plaintext/payload of the COSE 1669 object. The 'protected' field of the COSE object 'Headers' shall 1670 include the context identifier, both for requests and responses. If 1671 the unprotected CoAP message includes a Content-Format option, then 1672 the COSE object shall include a protected 'content type' field, whose 1673 value is set to the unprotected message Content-Format value. The 1674 Content-Format option of the protected CoAP message shall be replaced 1675 with "application/oscon" (Section 11) 1676 The COSE object shall be protected (encrypted) and verified 1677 (decrypted) as described in ([I-D.ietf-cose-msg]). 1679 Most AEAD algorithms require a unique nonce for each message. 1680 Sequence numbers for partial IV as specified for OSCOAP may be used 1681 for replay protection as described in Section 6. The use of time 1682 stamps in the COSE header parameter 'operation time' 1683 [I-D.ietf-cose-msg] for freshness may be used. 1685 OSCON shall not be used in cases where CoAP header fields (such as 1686 Code or Version) or CoAP options need to be integrity protected or 1687 encrypted. OSCON shall not be used in cases which require a secure 1688 binding between request and response. 1690 The scenarios in Sections 3.3 - 3.5 of 1691 [I-D.hartke-core-e2e-security-reqs] assume multiple recipients for a 1692 particular content. In this case the use of symmetric keys does not 1693 provide data origin authentication. Therefore the COSE object should 1694 in general be protected with a digital signature. 1696 D.1. Overhead OSCON 1698 In general there are four different kinds of modes that need to be 1699 supported: message authentication code, digital signature, 1700 authenticated encryption, and symmetric encryption + digital 1701 signature. The use of digital signature is necessary for 1702 applications with many legitimate recipients of a given message, and 1703 where data origin authentication is required. 1705 To distinguish between these different cases, the tagged structures 1706 of COSE are used (see Section 2 of [I-D.ietf-cose-msg]). 1708 The sizes of COSE messages for selected algorithms are detailed in 1709 this section. 1711 The size of the header is shown separately from the size of the MAC/ 1712 signature. A 4-byte Context Identifier and a 1-byte Sequence Number 1713 are used throughout all examples, with these values: 1715 o Cid: 0xa1534e3c 1717 o Seq: 0xa3 1719 For each scheme, we indicate the fixed length of these two parameters 1720 ("Cid+Seq" column) and of the Tag ("MAC"/"SIG"/"TAG"). The "Message 1721 OH" column shows the total expansions of the CoAP message size, while 1722 the "COSE OH" column is calculated from the previous columns. 1724 Overhead incurring from CBOR encoding is also included in the COSE 1725 overhead count. 1727 To make it easier to read, COSE objects are represented using CBOR's 1728 diagnostic notation rather than a binary dump. 1730 D.2. MAC Only 1732 This example is based on HMAC-SHA256, with truncation to 8 bytes 1733 (HMAC 256/64). 1735 Since the key is implicitly known by the recipient, the 1736 COSE_Mac0_Tagged structure is used (Section 6.2 of 1737 [I-D.ietf-cose-msg]). 1739 The object in COSE encoding gives: 1741 996( # COSE_Mac0_Tagged 1742 [ 1743 h'a20444a1534e3c0641a3', # protected: 1744 {04:h'a1534e3c', 1745 06:h'a3'} 1746 {}, # unprotected 1747 h'', # payload 1748 MAC # truncated 8-byte MAC 1749 ] 1750 ) 1752 This COSE object encodes to a total size of 26 bytes. 1754 Figure 8 summarizes these results. 1756 +------------------+-----+-----+---------+------------+ 1757 | Structure | Tid | MAC | COSE OH | Message OH | 1758 +------------------+-----+-----+---------+------------+ 1759 | COSE_Mac0_Tagged | 5 B | 8 B | 13 B | 26 B | 1760 +------------------+-----+-----+---------+------------+ 1762 Figure 8: Message overhead for a 5-byte Tid using HMAC 256/64 1764 D.3. Signature Only 1766 This example is based on ECDSA, with a signature of 64 bytes. 1768 Since only one signature is used, the COSE_Sign1_Tagged structure is 1769 used (Section 4.2 of [I-D.ietf-cose-msg]). 1771 The object in COSE encoding gives: 1773 997( # COSE_Sign1_Tagged 1774 [ 1775 h'a20444a1534e3c0641a3', # protected: 1776 {04:h'a1534e3c', 1777 06:h'a3'} 1778 {}, # unprotected 1779 h'', # payload 1780 SIG # 64-byte signature 1781 ] 1782 ) 1784 This COSE object encodes to a total size of 83 bytes. 1786 Figure 9 summarizes these results. 1788 +-------------------+-----+------+---------+------------+ 1789 | Structure | Tid | SIG | COSE OH | Message OH | 1790 +-------------------+-----+------+---------+------------+ 1791 | COSE_Sign1_Tagged | 5 B | 64 B | 14 B | 83 bytes | 1792 +-------------------+-----+------+---------+------------+ 1794 Figure 9: Message overhead for a 5-byte Tid using 64 byte ECDSA 1795 signature. 1797 D.4. Authenticated Encryption with Additional Data (AEAD) 1799 This example is based on AES-CCM with the Tag truncated to 8 bytes. 1801 Since the key is implicitly known by the recipient, the 1802 COSE_Encrypt0_Tagged structure is used (Section 5.2 of 1803 [I-D.ietf-cose-msg]). 1805 The object in COSE encoding gives: 1807 993( # COSE_Encrypt0_Tagged 1808 [ 1809 h'a20444a1534e3c0641a3', # protected: 1810 {04:h'a1534e3c', 1811 06:h'a3'} 1812 {}, # unprotected 1813 TAG # ciphertext + truncated 8-byte TAG 1814 ] 1815 ) 1817 This COSE object encodes to a total size of 25 bytes. 1819 Figure 10 summarizes these results. 1821 +----------------------+-----+-----+---------+------------+ 1822 | Structure | Tid | TAG | COSE OH | Message OH | 1823 +----------------------+-----+-----+---------+------------+ 1824 | COSE_Encrypt0_Tagged | 5 B | 8 B | 12 B | 25 bytes | 1825 +----------------------+-----+-----+---------+------------+ 1827 Figure 10: Message overhead for a 5-byte Tid using AES_128_CCM_8. 1829 D.5. Symmetric Encryption with Asymmetric Signature (SEAS) 1831 This example is based on AES-CCM and ECDSA with 64 bytes signature. 1832 The same assumption on the security context as in Appendix D.4. COSE 1833 defines the field 'counter signature w/o headers' that is used here 1834 to sign a COSE_Encrypt0_Tagged message (see Section 3 of 1835 [I-D.ietf-cose-msg]). 1837 The object in COSE encoding gives: 1839 993( # COSE_Encrypt0_Tagged 1840 [ 1841 h'a20444a1534e3c0641a3', # protected: 1842 {04:h'a1534e3c', 1843 06:h'a3'} 1844 {9:SIG}, # unprotected: 1845 09: 64 bytes signature 1846 TAG # ciphertext + truncated 8-byte TAG 1847 ] 1848 ) 1850 This COSE object encodes to a total size of 92 bytes. 1852 Figure 11 summarizes these results. 1854 +----------------------+-----+-----+------+---------+------------+ 1855 | Structure | Tid | TAG | SIG | COSE OH | Message OH | 1856 +----------------------+-----+-----+------+---------+------------+ 1857 | COSE_Encrypt0_Tagged | 5 B | 8 B | 64 B | 15 B | 92 B | 1858 +----------------------+-----+-----+------+---------+------------+ 1860 Figure 11: Message overhead for a 5-byte Tid using AES-CCM 1861 countersigned with ECDSA. 1863 Authors' Addresses 1865 Goeran Selander 1866 Ericsson AB 1868 Email: goran.selander@ericsson.com 1869 John Mattsson 1870 Ericsson AB 1872 Email: john.mattsson@ericsson.com 1874 Francesca Palombini 1875 Ericsson AB 1877 Email: francesca.palombini@ericsson.com 1879 Ludwig Seitz 1880 SICS Swedish ICT 1882 Email: ludwig@sics.se