idnits 2.17.00 (12 Aug 2021) /tmp/idnits3454/draft-hoeglund-core-oscore-key-limits-02.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1034): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. 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 (25 October 2021) is 202 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) == Outdated reference: A later version (-13) exists of draft-ietf-lake-edhoc-12 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-04) exists of draft-irtf-cfrg-aead-limits-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group R. Höglund 3 Internet-Draft M. Tiloca 4 Updates: 8613 (if approved) RISE AB 5 Intended status: Standards Track 25 October 2021 6 Expires: 28 April 2022 8 Key Update for OSCORE (KUDOS) 9 draft-hoeglund-core-oscore-key-limits-02 11 Abstract 13 Object Security for Constrained RESTful Environments (OSCORE) uses 14 AEAD algorithms to ensure confidentiality and integrity of exchanged 15 messages. Due to known issues allowing forgery attacks against AEAD 16 algorithms, limits should be followed on the number of times a 17 specific key is used for encryption or decryption. This document 18 defines how two OSCORE peers must follow these limits and what steps 19 they must take to preserve the security of their communications. 20 Therefore, this document updates RFC8613. Furthermore, this document 21 specifies Key Update for OSCORE (KUDOS), a lightweight procedure that 22 two peers can use to update their keying material and establish a new 23 OSCORE Security Context. 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 https://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 28 April 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. AEAD Key Usage Limits in OSCORE . . . . . . . . . . . . . . . 3 61 2.1. Problem Overview . . . . . . . . . . . . . . . . . . . . 3 62 2.1.1. Limits for 'q' and 'v' . . . . . . . . . . . . . . . 4 63 2.2. Additional Information in the Security Context . . . . . 7 64 2.2.1. Common Context . . . . . . . . . . . . . . . . . . . 7 65 2.2.2. Sender Context . . . . . . . . . . . . . . . . . . . 7 66 2.2.3. Recipient Context . . . . . . . . . . . . . . . . . . 8 67 2.3. OSCORE Messages Processing . . . . . . . . . . . . . . . 8 68 2.3.1. Protecting a Request or a Response . . . . . . . . . 8 69 2.3.2. Verifying a Request or a Response . . . . . . . . . . 9 70 3. Current methods for Rekeying OSCORE . . . . . . . . . . . . . 9 71 4. Key Update for OSCORE (KUDOS) . . . . . . . . . . . . . . . . 11 72 4.1. Extensions to the OSCORE Option . . . . . . . . . . . . . 12 73 4.2. Function for Security Context Update . . . . . . . . . . 13 74 4.3. Establishment of the New OSCORE Security Context . . . . 15 75 4.3.1. Client-Initiated Key Update . . . . . . . . . . . . . 16 76 4.3.2. Server-Initiated Key Update . . . . . . . . . . . . . 18 77 4.4. Retention Policies . . . . . . . . . . . . . . . . . . . 21 78 4.5. Discussion . . . . . . . . . . . . . . . . . . . . . . . 21 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 81 6.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . . 22 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 83 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 84 7.2. Informative References . . . . . . . . . . . . . . . . . 23 85 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 Object Security for Constrained RESTful Environments (OSCORE) 91 [RFC8613] provides end-to-end protection of CoAP [RFC7252] messages 92 at the application-layer, ensuring message confidentiality and 93 integrity, replay protection, as well as binding of response to 94 request between a sender and a recipient. 96 In particular, OSCORE uses AEAD algorithms to provide confidentiality 97 and integrity of messages exchanged between two peers. Due to known 98 issues allowing forgery attacks against AEAD algorithms, limits 99 should be followed on the number of times a specific key is used to 100 perform encryption or decryption [I-D.irtf-cfrg-aead-limits]. 102 Should these limits be exceeded, an adversary may break the security 103 properties of the AEAD algorithm, such as message confidentiality and 104 integrity, e.g. by performing a message forgery attack. The original 105 OSCORE specification [RFC8613] does not consider such limits. 107 This document updates [RFC8613] as follows. 109 * It defines when a peer must stop using an OSCORE Security Context 110 shared with another peer, due to the reached key usage limits. 111 When this happens, the two peers have to establish a new Security 112 Context with new keying material, in order to continue their 113 secure communication with OSCORE. 115 * It specifies KUDOS, a lightweight key update procedure that the 116 two peers can use in order to update their current keying material 117 and establish a new OSCORE Security Context. This deprecates and 118 replaces the procedure specified in Appendix B.2 of [RFC8613]. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 Readers are expected to be familiar with the terms and concepts 129 related to the CoAP [RFC7252] and OSCORE [RFC8613] protocols. 131 2. AEAD Key Usage Limits in OSCORE 133 The following sections details how key usage limits for AEAD 134 algorithms must be considered when using OSCORE. It covers specific 135 limits for common AEAD algorithms used with OSCORE; necessary 136 additions to the OSCORE Security Context, updates to the OSCORE 137 message processing, and existing methods for rekeying OSCORE. 139 2.1. Problem Overview 141 The OSCORE security protocol [RFC8613] uses AEAD algorithms to 142 provide integrity and confidentiality of messages, as exchanged 143 between two peers sharing an OSCORE Security Context. 145 When processing messages with OSCORE, each peer should follow 146 specific limits as to the number of times it uses a specific key. 147 This applies separately to the Sender Key used to encrypt outgoing 148 messages, and to the Recipient Key used to decrypt and verify 149 incoming protected messages. 151 Exceeding these limits may allow an adversary to break the security 152 properties of the AEAD algorithm, such as message confidentiality and 153 integrity, e.g. by performing a message forgery attack. 155 The following refers to the two parameters 'q' and 'v' introduced in 156 [I-D.irtf-cfrg-aead-limits], to use when deploying an AEAD algorithm. 158 * 'q': this parameter has as value the number of messages protected 159 with a specific key, i.e. the number of times the AEAD algorithm 160 has been invoked to encrypt data with that key. 162 * 'v': this parameter has as value the number of alleged forgery 163 attempts that have been made against a specific key, i.e. the 164 amount of failed decryptions that has been done with the AEAD 165 algorithm for that key. 167 When a peer uses OSCORE: 169 * The key used to protect outgoing messages is its Sender Key, in 170 its Sender Context. 172 * The key used to decrypt and verify incoming messages is its 173 Recipient Key, in its Recipient Context. 175 Both keys are derived as part of the establishment of the OSCORE 176 Security Context, as defined in Section 3.2 of [RFC8613]. 178 As mentioned above, exceeding specific limits for the 'q' or 'v' 179 value can weaken the security properties of the AEAD algorithm used, 180 thus compromising secure communication requirements. 182 Therefore, in order to preserve the security of the used AEAD 183 algorithm, OSCORE has to observe limits for the 'q' and 'v' values, 184 throughout the lifetime of the used AEAD keys. 186 2.1.1. Limits for 'q' and 'v' 188 Formulas for calculating the security levels as Integrity Advantage 189 (IA) and Confidentiality Advantage (CA) probabilities, are presented 190 in [I-D.irtf-cfrg-aead-limits]. These formulas take as input 191 specific values for 'q' and 'v' (see section Section 2.1) and for 192 'l', i.e., the maximum length of each message (in cipher blocks). 194 For the algorithms that can be used as AEAD Algorithm for OSCORE 195 shows in Figure 1, the key property to achieve is having IA and CA 196 values which are no larger than p = 2^-64, which will ensure a safe 197 security level for the AEAD Algorithm. This can be entailed by using 198 the values q = 2^20, v = 2^20, and l = 2^10, that this document 199 recommends to use for these algorithms. 201 Figure 1 shows the resulting IA and CA probabilities enjoyed by the 202 considered algorithms, when taking the value of 'q', 'v' and 'l' 203 above as input to the formulas defined in 204 [I-D.irtf-cfrg-aead-limits]. 206 +------------------------+----------------+----------------+ 207 | Algorithm name | IA probability | CA probability | 208 |------------------------+----------------+----------------| 209 | AEAD_AES_128_CCM | 2^-64 | 2^-66 | 210 | AEAD_AES_128_GCM | 2^-97 | 2^-89 | 211 | AEAD_AES_256_GCM | 2^-97 | 2^-89 | 212 | AEAD_CHACHA20_POLY1305 | 2^-73 | - | 213 +------------------------+----------------+----------------+ 215 Figure 1: Probabilities for algorithms based on chosen q, v and l 216 values. 218 For the AEAD_AES_128_CCM_8 algorithm when used as AEAD Algorithm for 219 OSCORE, larger IA and CA values are achieved, depending on the value 220 of 'q', 'v' and 'l'. Figure 2 shows the resulting IA and CA 221 probabilities enjoyed by AEAD_AES_128_CCM_8, when taking different 222 values of 'q', 'v' and 'l' as input to the formulas defined in 223 [I-D.irtf-cfrg-aead-limits]. 225 As shown in Figure 2, it is especially possible to achieve the lowest 226 IA = 2^-54 and a good CA = 2^-70 by considering the largest possible 227 value of the (q, v, l) triplet equal to (2^20, 2^10, 2^8), while 228 still keeping a good security level. Note that the value of 'l' does 229 not impact on IA, while CA displays good values for every considered 230 value of 'l'. 232 When AEAD_AES_128_CCM_8 is used as AEAD Algorithm for OSCORE, this 233 document recommends to use the triplet (q, v, l) = (2^20, 2^10, 2^8) 234 and to never use a triplet (q, v, l) such that the resulting IA and 235 CA probabilities are higher than 2^-54. 237 +-----------------------+----------------+----------------+ 238 | 'q', 'v' and 'l' | IA probability | CA probability | 239 |-----------------------+----------------+----------------| 240 | q=2^20, v=2^20, l=2^8 | 2^-44 | 2^-70 | 241 | q=2^15, v=2^20, l=2^8 | 2^-44 | 2^-80 | 242 | q=2^10, v=2^20, l=2^8 | 2^-44 | 2^-90 | 243 | q=2^20, v=2^15, l=2^8 | 2^-49 | 2^-70 | 244 | q=2^15, v=2^15, l=2^8 | 2^-49 | 2^-80 | 245 | q=2^10, v=2^15, l=2^8 | 2^-49 | 2^-90 | 246 | q=2^20, v=2^14, l=2^8 | 2^-50 | 2^-70 | 247 | q=2^15, v=2^14, l=2^8 | 2^-50 | 2^-80 | 248 | q=2^10, v=2^14, l=2^8 | 2^-50 | 2^-90 | 249 | q=2^20, v=2^10, l=2^8 | 2^-54 | 2^-70 | 250 | q=2^15, v=2^10, l=2^8 | 2^-54 | 2^-80 | 251 | q=2^10, v=2^10, l=2^8 | 2^-54 | 2^-90 | 252 |-----------------------+----------------+----------------| 253 | q=2^20, v=2^20, l=2^6 | 2^-44 | 2^-74 | 254 | q=2^15, v=2^20, l=2^6 | 2^-44 | 2^-84 | 255 | q=2^10, v=2^20, l=2^6 | 2^-44 | 2^-94 | 256 | q=2^20, v=2^15, l=2^6 | 2^-49 | 2^-74 | 257 | q=2^15, v=2^15, l=2^6 | 2^-49 | 2^-84 | 258 | q=2^10, v=2^15, l=2^6 | 2^-49 | 2^-94 | 259 | q=2^20, v=2^14, l=2^6 | 2^-50 | 2^-74 | 260 | q=2^15, v=2^14, l=2^6 | 2^-50 | 2^-84 | 261 | q=2^10, v=2^14, l=2^6 | 2^-50 | 2^-94 | 262 | q=2^20, v=2^10, l=2^6 | 2^-54 | 2^-74 | 263 | q=2^15, v=2^10, l=2^6 | 2^-54 | 2^-84 | 264 | q=2^10, v=2^10, l=2^6 | 2^-54 | 2^-94 | 265 +-----------------------+----------------+----------------+ 267 Figure 2: Probabilities for AEAD_AES_128_CCM_8 based on chosen q, 268 v and l values. 270 The algorithms using AES presented in this draft all use a block size 271 of 16 bytes (128 bits), while AEAD_CHACHA20_POLY1305 uses a block 272 size of 64 bytes (512 bits). As 'l' is defined as the maximum size 273 of each message in blocks, different block sizes will result in 274 different maximum messages sizes for the same value of 'l'. Figure 3 275 presents the resulting maximum message size in bytes for the 276 different algorithms and values of 'l' presented in this document. 278 +------------------------+----------+----------+-----------+ 279 | Algorithm name | l=2^6 in | l=2^8 in | l=2^10 in | 280 | | bytes | bytes | bytes | 281 |------------------------+----------+----------|-----------| 282 | AEAD_AES_128_CCM | 1024 | 4096 | 16384 | 283 | AEAD_AES_128_GCM | 1024 | 4096 | 16384 | 284 | AEAD_AES_256_GCM | 1024 | 4096 | 16384 | 285 | AEAD_AES_128_CCM_8 | 1024 | 4096 | 16384 | 286 | AEAD_CHACHA20_POLY1305 | 4096 | 16384 | 65536 | 287 +------------------------+----------+----------+-----------+ 289 Figure 3: Maximum length of each message (in bytes) 291 2.2. Additional Information in the Security Context 293 In addition to what defined in Section 3.1 of [RFC8613], the OSCORE 294 Security Context MUST also include the following information. 296 2.2.1. Common Context 298 The Common Context is extended to include the following parameter. 300 * 'exp': with value the expiration time of the OSCORE Security 301 Context, as a non-negative integer. The parameter contains a 302 numeric value representing the number of seconds from 303 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 304 ignoring leap seconds, analogous to what specified for NumericDate 305 in Section 2 of [RFC7519]. 307 At the time indicated in this field, a peer MUST stop using this 308 Security Context to process any incoming or outgoing message, and 309 is required to establish a new Security Context to continue 310 OSCORE-protected communications with the other peer. 312 2.2.2. Sender Context 314 The Sender Context is extended to include the following parameters. 316 * 'count_q': a non-negative integer counter, keeping track of the 317 current 'q' value for the Sender Key. At any time, 'count_q' has 318 as value the number of messages that have been encrypted using the 319 Sender Key. The value of 'count_q' is set to 0 when establishing 320 the Sender Context. 322 * 'limit_q': a non-negative integer, which specifies the highest 323 value that 'count_q' is allowed to reach, before stopping using 324 the Sender Key to process outgoing messages. 326 The value of 'limit_q' depends on the AEAD algorithm specified in 327 the Common Context, considering the properties of that algorithm. 328 The value of 'limit_q' is determined according to Section 2.1.1. 330 2.2.3. Recipient Context 332 The Recipient Context is extended to include the following 333 parameters. 335 * 'count_v': a non-negative integer counter, keeping track of the 336 current 'v' value for the Recipient Key. At any time, 'count_v' 337 has as value the number of failed decryptions occurred on incoming 338 messages using the Recipient Key. The value of 'count_v' is set to 339 0 when establishing the Recipient Context. 341 * 'limit_v': a non-negative integer, which specifies the highest 342 value that 'count_v' is allowed to reach, before stopping using 343 the Recipient Key to process incoming messages. 345 The value of 'limit_v' depends on the AEAD algorithm specified in 346 the Common Context, considering the properties of that algorithm. 347 The value of 'limit_v' is determined according to Section 2.1.1. 349 2.3. OSCORE Messages Processing 351 In order to keep track of the 'q' and 'v' values and ensure that AEAD 352 keys are not used beyond reaching their limits, the processing of 353 OSCORE messages is extended as defined in this section. A limitation 354 that is introduced is that, in order to not exceed the selected value 355 for 'l', the total size of the COSE plaintext, authentication Tag, 356 and possible cipher padding for a message may not exceed the block 357 size for the selected algorithm multiplied with 'l'. 359 In particular, the processing of OSCORE messages follows the steps 360 outlined in Section 8 of [RFC8613], with the additions defined below. 362 2.3.1. Protecting a Request or a Response 364 Before encrypting the COSE object using the Sender Key, the 'count_q' 365 counter MUST be incremented. 367 If 'count_q' exceeds the 'limit_q' limit, the message processing MUST 368 be aborted. From then on, the Sender Key MUST NOT be used to encrypt 369 further messages. 371 2.3.2. Verifying a Request or a Response 373 If an incoming message is detected to be a replay (see Section 7.4 of 374 [RFC8613]), the 'count_v' counter MUST NOT be incremented. 376 If the decryption and verification of the COSE object using the 377 Recipient Key fails, the 'count_v' counter MUST be incremented. 379 After 'count_v' has exceeded the 'limit_v' limit, incoming messages 380 MUST NOT be decrypted and verified using the Recipient Key, and their 381 processing MUST be aborted. 383 3. Current methods for Rekeying OSCORE 385 Before the limit of 'q' or 'v' defined in Section 2.1.1 has been 386 reached for an OSCORE Security Context, the two peers have to 387 establish a new OSCORE Security Context, in order to continue using 388 OSCORE for secure communication. 390 In practice, the two peers have to establish new Sender and Recipient 391 Keys, as the keys actually used by the AEAD algorithm. When this 392 happens, both peers reset their 'count_q' and 'count_v' values to 0 393 (see Section 2.2). 395 Other specifications define a number of ways to accomplish this, as 396 summarized below. 398 * The two peers can run the procedure defined in Appendix B.2 of 399 [RFC8613]. That is, the two peers exchange three or four 400 messages, protected with temporary Security Contexts adding 401 randomness to the ID Context. 403 As a result, the two peers establish a new OSCORE Security Context 404 with new ID Context, Sender Key and Recipient Key, while keeping 405 the same OSCORE Master Secret and OSCORE Master Salt from the old 406 OSCORE Security Context. 408 This procedure does not require any additional components to what 409 OSCORE already provides, and it does not provide perfect forward 410 secrecy. 412 The procedure defined in Appendix B.2 of [RFC8613] is used in 413 6TiSCH networks [RFC7554][RFC8180] when handling failure events. 414 That is, a node acting as Join Registrar/Coordinator (JRC) assists 415 new devices, namely "pledges", to securely join the network as per 416 the Constrained Join Protocol [RFC9031]. In particular, a pledge 417 exchanges OSCORE-protected messages with the JRC, from which it 418 obtains a short identifier, link-layer keying material and other 419 configuration parameters. As per Section 8.3.3 of [RFC9031], a 420 JRC that experiences a failure event may likely lose information 421 about joined nodes, including their assigned identifiers. Then, 422 the reinitialized JRC can establish a new OSCORE Security Context 423 with each pledge, through the procedure defined in Appendix B.2 of 424 [RFC8613]. 426 * The two peers can run the OSCORE profile 427 [I-D.ietf-ace-oscore-profile] of the Authentication and 428 Authorization for Constrained Environments (ACE) Framework 429 [I-D.ietf-ace-oauth-authz]. 431 When a CoAP client uploads an Access Token to a CoAP server as an 432 access credential, the two peers also exchange two nonces. Then, 433 the two peers use the two nonces together with information 434 provided by the ACE Authorization Server that issued the Access 435 Token, in order to derive an OSCORE Security Context. 437 This procedure does not provide perfect forward secrecy. 439 * The two peers can run the EDHOC key exchange protocol based on 440 Diffie-Hellman and defined in [I-D.ietf-lake-edhoc], in order to 441 establish a pseudo-random key in a mutually authenticated way. 443 Then, the two peers can use the established pseudo-random key to 444 derive external application keys. This allows the two peers to 445 securely derive especially an OSCORE Master Secret and an OSCORE 446 Master Salt, from which an OSCORE Security Context can be 447 established. 449 This procedure additionally provides perfect forward secrecy. 451 * If one peer is acting as LwM2M Client and the other peer as LwM2M 452 Server, according to the OMA Lightweight Machine to Machine Core 453 specification [LwM2M], then the LwM2M Client peer may take the 454 initiative to bootstrap again with the LwM2M Bootstrap Server, and 455 receive again an OSCORE Security Context. Alternatively, the 456 LwM2M Server can instruct the LwM2M Client to initiate this 457 procedure. 459 If the OSCORE Security Context information on the LwM2M Bootstrap 460 Server has been updated, the LwM2M Client will thus receive a 461 fresh OSCORE Security Context to use with the LwM2M Server. 463 In addition to that, the LwM2M Client, the LwM2M Server as well as 464 the LwM2M Bootstrap server are required to use the procedure 465 defined in Appendix B.2 of [RFC8613] and overviewed above, when 466 they use a certain OSCORE Security Context for the first time 467 [LwM2M-Transport]. 469 Manually updating the OSCORE Security Context at the two peers should 470 be a last resort option, and it might often be not practical or 471 feasible. 473 Even when any of the alternatives mentioned above is available, it is 474 RECOMMENDED that two OSCORE peers update their Security Context by 475 using the KUDOS procedure as defined in Section 4 of this document. 477 It is RECOMMENDED that the peer initiating the key update procedure 478 starts it before reaching the 'q' or 'v' limits. Otherwise, the AEAD 479 keys possibly to be used during the key update procedure itself may 480 already be or become invalid before the rekeying is completed, which 481 may prevent a successful establishment of the new OSCORE Security 482 Context altogether. 484 4. Key Update for OSCORE (KUDOS) 486 This section defines KUDOS, a lightweight procedure that two OSCORE 487 peers can use to update their keying material and establish a new 488 OSCORE Security Context. 490 KUDOS relies on the support function updateCtx() defined in 491 Section 4.2 and the message exchange defined in Section 4.3. The 492 following properties are fulfilled. 494 * KUDOS can be initiated by either peer. In particular, the client 495 or the server may start KUDOS by sending the first rekeying 496 message. 498 * The new OSCORE Security Context enjoys Perfect Forward Secrecy. 500 * The same ID Context value used in the old OSCORE Security Context 501 is preserved in the new Security Context. Furthermore, the ID 502 Context value never changes throughout the KUDOS execution. 504 * KUDOS is robust against a peer rebooting, and it especially avoids 505 the reuse of AEAD (nonce, key) pairs. 507 * KUDOS completes in one round trip. The two peers achieve mutual 508 proof-of-possession in the following exchange, which is protected 509 with the newly established OSCORE Security Context. 511 4.1. Extensions to the OSCORE Option 513 In order to support the message exchange for establishing a new 514 OSCORE Security Context as defined in Section 4.3, this document 515 extends the use of the OSCORE option originally defined in [RFC8613] 516 as follows. 518 * This document defines the usage of the seventh least significant 519 bit, called "Extension-1 Flag", in the first byte of the OSCORE 520 option containing the OSCORE flag bits. This flag bit is 521 specified in Section 6.1. 523 When the Extension-1 Flag is set to 1, the second byte of the 524 OSCORE option MUST include the set of OSCORE flag bits 8-15. 526 * This document defines the usage of the first least significant bit 527 "ID Detail Flag", 'd', in the second byte of the OSCORE option 528 containing the OSCORE flag bits. This flag bit is specified in 529 Section 6.1. 531 When it is set to 1, the compressed COSE object contains an 'id 532 detail', to be used for the steps defined in Section 4.3. In 533 particular, the 1 byte following 'kid context' (if any) encodes 534 the length x of 'id detail', and the following x bytes encode 'id 535 detail'. 537 * The second-to-eighth least significant bits in the second byte of 538 the OSCORE option containing the OSCORE flag bits are reserved for 539 future use. These bits SHALL be set to zero when not in use. 540 According to this specification, if any of these bits are set to 541 1, the message is considered to be malformed and decompression 542 fails as specified in item 2 of Section 8.2 of [RFC8613]. 544 Figure 4 shows the OSCORE option value including also 'id detail'. 546 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <----- n bytes -----> 547 +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ 548 |0|1|0|h|k| n | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) | 549 +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ 551 <- 1 byte -> <----- s bytes ------> <- 1 byte -> <----- x bytes ----> 552 +------------+----------------------+---------------------------------+ 553 | s (if any) | kid context (if any) | x (if any) | id detail (if any) | 554 +------------+----------------------+------------+--------------------+ 556 +------------------+ 557 | kid (if any) ... | 558 +------------------+ 559 Figure 4: The OSCORE option value, including 'id detail' 561 4.2. Function for Security Context Update 563 The updateCtx() function shown in Figure 5 takes as input a nonce N 564 as well as an OSCORE Security Context CTX_IN, and returns as output a 565 new OSCORE Security Context CTX_OUT. 567 As a first step, the updateCtx() function derives the new values of 568 the Master Secret and Master Salt for CTX_OUT, according to one of 569 the two following methods. The used method depends on how the two 570 peers established their original Security Context, i.e., the Security 571 Context that they shared before performing KUDOS with one another for 572 the first time. 574 * If the original Security Context was established by running the 575 EDHOC protocol [I-D.ietf-lake-edhoc], the following applies. 577 First, the EDHOC key PRK_4x3m shared by the two peers is updated 578 using the EDHOC-KeyUpdate() function defined in Section 4.4 of 579 [I-D.ietf-lake-edhoc], which takes the nonce N as input. 581 After that, the EDHOC-Exporter() function defined in Section 4.3 582 of [I-D.ietf-lake-edhoc] is used to derive the new values for the 583 Master Secret and Master Salt, consistently with what is defined 584 in Appendix A.2 of [I-D.ietf-lake-edhoc]. In particular, the 585 context parameter provided as second argument to the EDHOC- 586 Exporter() function is the empty CBOR byte string (0x40) 587 [RFC8949], which is denoted as h''. 589 Note that, compared to the compliance requirements in Section 7 of 590 [I-D.ietf-lake-edhoc], a peer MUST support the EDHOC-KeyUpdate() 591 function, in case it establishes an original Security Context 592 through the EDHOC protocol and intends to perform KUDOS. 594 * If the original Security Context was established through other 595 means than the EDHOC protocol, the new Master Secret is derived 596 through an HKDF-Expand() step, which takes as input N as well as 597 the Master Secret value from the Security Context CTX_IN. 598 Instead, the new Master Salt takes N as value. 600 In either case, the derivation of new values follows the same 601 approach used in TLS 1.3, which is also based on HKDF-Expand (see 602 Section 7.1 of [RFC8446]) and used for computing new keying material 603 in case of key update (see Section 4.6.3 of [RFC8446]). 605 After that, the new Master Secret and Master Salt parameters are used 606 to derive a new Security Context CTX_OUT as per Section 3.2 of 607 [RFC8613]. Any other parameter required for the derivation takes the 608 same value as in the Security Context CTX_IN. Finally, the function 609 returns the newly derived Security Context CTX_OUT. 611 updateCtx(N, CTX_IN) { 613 CTX_OUT // The new Security Context 614 MSECRET_NEW // The new Master Secret 615 MSALT_NEW // The new Master Salt 617 if { 619 EDHOC-KeyUpdate(N) 620 // This results in updating the key PRK_4x3m of the 621 // EDHOC session, i.e., PRK_4x3m = Extract(N, PRK_4x3m) 623 MSECRET_NEW = EDHOC-Exporter("OSCORE_Master_Secret", 624 h'', key_length) 625 = EDHOC-KDF(PRK_4x3m, TH_4, 626 "OSCORE_Master_Secret", h'', key_length) 628 MSALT_NEW = EDHOC-Exporter("OSCORE_Master_Salt", 629 h'', salt_length) 630 = EDHOC-KDF(PRK_4x3m, TH_4, 631 "OSCORE_Master_Salt", h'', salt_length) 633 } 634 else { 635 Master Secret Length = < Size of CTX_IN.MasterSecret in bytes > 637 MSECRET_NEW = HKDF-Expand-Label(CTX_IN.MasterSecret, Label, 638 N, Master Secret Length) 639 = HKDF-Expand(CTX_IN.MasterSecret, HkdfLabel, 640 Master Secret Length) 642 MSALT_NEW = N; 643 } 645 < Derive CTX_OUT using MSECRET_NEW and MSALT_NEW, 646 together with other parameters from CTX_IN > 648 Return CTX_OUT; 650 } 652 Where HkdfLabel is defined as 653 struct { 654 uint16 length = Length; 655 opaque label<7..255> = "oscore " + Label; 656 opaque context<0..255> = Context; 657 } HkdfLabel; 659 Figure 5: Function for deriving a new OSCORE Security Context 661 4.3. Establishment of the New OSCORE Security Context 663 This section defines the actual KUDOS procedure performed by two 664 peers to update their OSCORE keying material. Before starting KUDOS, 665 the two peers share the OSCORE Security Context CTX_OLD. Once 666 completed the KUDOS execution, the two peers agree on a newly 667 established OSCORE Security Context CTX_NEW. 669 In particular, each peer contributes by generating a fresh value R1 670 or R2, and providing it to the other peer. The byte string 671 concatenation of the two values, hereafter denoted as R1 | R2, is 672 used as input N by the updateCtx() function, in order to derive the 673 new OSCORE Security Context CTX_NEW. As for any new OSCORE Security 674 Context, the Sender Sequence Number and the replay window are re- 675 initialized accordingly (see Section 3.2.2 of [RFC8613]). 677 Once a peer has successfully derived the new OSCORE Security Context 678 CTX_NEW, that peer MUST terminate all the ongoing observations it has 679 with the other peer as protected with the old Security Context 680 CTX_OLD. 682 Once a peer has successfully decrypted and verified an incoming 683 message protected with CTX_NEW, that peer MUST discard the old 684 Security Context CTX_OLD. 686 KUDOS can be started by the client or the server, as defined in 687 Section 4.3.1 and Section 4.3.2, respectively. The following 688 properties hold for both the client- and server-initiated version of 689 KUDOS. 691 * The initiator always offers the fresh value R1. 693 * The responder always offers the fresh value R2. 695 * The responder is always the first one deriving the new OSCORE 696 Security Context CTX_NEW. 698 * The initiator is always the first one achieving key confirmation, 699 hence able to safely discard the old OSCORE Security Context 700 CTX_OLD. 702 * Both the initiator and the responder use the same respective 703 OSCORE Sender ID and Recipient ID. Also, they both preserve and 704 use the same OSCORE ID Context from CTX_OLD. 706 The length of the nonces R1, and R2 is application specific. The 707 application needs to set the length of each nonce such that the 708 probability of its value being repeated is negligible; typically, at 709 least 8 bytes long. 711 4.3.1. Client-Initiated Key Update 713 Figure 6 shows the KUDOS workflow with the client acting as 714 initiator. 716 Client Server 717 (initiator) (responder) 718 | | 719 Generate R1 | | 720 | | 721 CTX_1 = | | 722 updateCtx(R1, | | 723 CTX_OLD) | | 724 | | 725 | Request #1 | 726 Protect with CTX_1 |------------------->| 727 | OSCORE Option: | CTX_1 = 728 | ... | update(R1, 729 | d flag: 1 | CTX_OLD) 730 | ... | 731 | ID Detail: R1 | Verify with CTX_1 732 | ... | 733 | | Generate R2 734 | | 735 | | CTX_NEW = 736 | | update(R1|R2, 737 | | CTX_OLD) 738 | | 739 | Response #1 | 740 |<-------------------| Protect with CTX_NEW 741 CTX_NEW = | OSCORE Option: | 742 updateCtx(R1|R2, | ... | 743 CTX_OLD) | d flag: 1 | 744 | ... | 745 Verify with CTX_NEW | ID Detail: R2 | 746 | ... | 747 Discard CTX_OLD | | 748 | | 750 // The actual key update process ends here. 751 // The two peers can use the new Security Context CTX_NEW. 753 | | 754 | Request #2 | 755 Protect with CTX_NEW |------------------->| 756 | | Verify with CTX_NEW 757 | | 758 | | Discard CTX_OLD 759 | | 760 | Response #2 | 761 |<-------------------| Protect with CTX_NEW 762 Verify with CTX_NEW | | 763 | | 765 Figure 6: Client-Initiated KUDOS Workflow 767 First, the client generates a random value R1, and uses the nonce N = 768 R1 together with the old Security Context CTX_OLD, in order to derive 769 a temporary Security Context CTX_1. Then, the client sends an OSCORE 770 request to the server, protected with the Security Context CTX_1. In 771 particular, the request has the 'd' flag bit set to 1 and specifies 772 R1 as 'id detail' (see Section 4.1). 774 Upon receiving the OSCORE request, the server retrieves the value R1 775 from the 'id detail' of the request, and uses the nonce N = R1 776 together with the old Security Context CTX_OLD, in order to derive 777 the temporary Security Context CTX_1. Then, the server verifies the 778 request by using the Security Context CTX_1. 780 After that, the server generates a random value R2, and uses the 781 nonce N = R1 | R2 together with the old Security Context CTX_OLD, in 782 order to derive the new Security Context CTX_NEW. Then, the server 783 sends an OSCORE response to the client, protected with the new 784 Security Context CTX_NEW. In particular, the response has the 'd' 785 flag bit set to 1 and specifies R2 as 'id detail'. 787 Upon receiving the OSCORE response, the client retrieves the value R2 788 from the 'id detail' of the response. Since the client has received 789 a response to an OSCORE request it made with the 'd' flag bit set to 790 1, the client uses the nonce N = R1 | R2 together with the old 791 Security Context CTX_OLD, in order to derive the new Security Context 792 CTX_NEW. Finally, the client verifies the response by using the 793 Security Context CTX_NEW and deletes the old Security Context 794 CTX_OLD. 796 After that, the client can send a new OSCORE request protected with 797 the new Security Context CTX_NEW. When successfully verifying the 798 request using the Security Context CTX_NEW, the server deletes the 799 old Security Context CTX_OLD and can reply with an OSCORE response 800 protected with the new Security Context CTX_NEW. 802 From then on, the two peers can protect their message exchanges by 803 using the new Security Context CTX_NEW. 805 4.3.2. Server-Initiated Key Update 807 Figure 7 shows the KUDOS workflow with the server acting as 808 initiator. 810 Client Server 811 (responder) (initiator) 812 | | 813 | Request #1 | 814 Protect with CTX_OLD |------------------->| 815 | | Verify with CTX_OLD 816 | | 817 | | Generate R1 818 | | 819 | | CTX_1 = 820 | | updateCtx(R1, 821 | | CTX_OLD) 822 | | 823 | Response #1 | 824 |<-------------------| Protect with CTX_1 825 CTX_1 = | OSCORE Option: | 826 updateCtx(R1, | ... | 827 CTX_OLD) | d flag: 1 | 828 | ... | 829 Verify with CTX_1 | ID Detail: R1 | 830 | ... | 831 Generate R2 | | 832 | | 833 CTX_NEW = | | 834 updateCtx(R1|R2, | | 835 CTX_OLD) | | 836 | | 837 | Request #2 | 838 Protect with CTX_NEW |------------------->| 839 | OSCORE Option: | CTX_NEW = 840 | ... | updateCtx(R1|R2, 841 | d flag: 1 | CTX_OLD) 842 | ... | 843 | ID Detail: R1|R2 | Verify with CTX_NEW 844 | ... | 845 | | Discard CTX_OLD 846 | | 848 // The actual key update process ends here. 849 // The two peers can use the new Security Context CTX_NEW. 851 | Response #2 | 852 |<-------------------| Protect with CTX_NEW 853 Verify with CTX_NEW | | 854 | | 855 Discard CTX_OLD | | 856 | | 858 Figure 7: Server-Initiated KUDOS Workflow 860 First, the client sends a normal OSCORE request to the server, 861 protected with the old Security Context CTX_OLD and with the 'd' flag 862 bit set to 0. 864 Upon receiving the OSCORE request and after having verified it with 865 the old Security Context CTX_OLD as usual, the server generates a 866 random value R1 and uses the nonce N = R1 together with the old 867 Security Context CTX_OLD, in order to derive a temporary Security 868 Context CTX_1. Then, the server sends an OSCORE response to the 869 client, protected with the Security Context CTX_1. In particular, 870 the response has the 'd' flag bit set to 1 and specifies R1 as 'id 871 detail' (see Section 4.1). 873 Upon receiving the OSCORE response, the client retrieves the value R1 874 from the 'id detail' of the response, and uses the nonce N = R1 875 together with the old Security Context CTX_OLD, in order to derive 876 the temporary Security Context CTX_1. Then, the client verifies the 877 response by using the Security Context CTX_1. 879 After that, the client generates a random value R2, and uses the 880 nonce N = R1 | R2 together with the old Security Context CTX_OLD, in 881 order to derive the new Security Context CTX_NEW. Then, the client 882 sends an OSCORE request to the server, protected with the new 883 Security Context CTX_NEW. In particular, the request has the 'd' 884 flag bit set to 1 and specifies R1 | R2 as 'id detail'. 886 Upon receiving the OSCORE request, the server retrieves the value 887 R1 | R2 from the request. Then, the server verifies that: i) the 888 value R1 is identical to the value R1 specified in a previous OSCORE 889 response with the 'd' flag bit set to 1; and ii) the value R1 | R2 890 has not been received before in an OSCORE request with the 'd' flag 891 bit set to 1. If the verification succeeds, the server uses the 892 nonce N = R1 | R2 together with the old Security Context CTX_OLD, in 893 order to derive the new Security Context CTX_NEW. Finally, the 894 server verifies the request by using the Security Context CTX_NEW and 895 deletes the old Security Context CTX_OLD. 897 After that, the server can send an OSCORE response protected with the 898 new Security Context CTX_NEW. When successfully verifying the 899 response using the Security Context CTX_NEW, the client deletes the 900 old Security Context CTX_OLD. 902 From then on, the two peers can protect their message exchanges by 903 using the new Security Context CTX_NEW. 905 4.4. Retention Policies 907 Applications MAY define policies that allows a peer to also 908 temporarily keep the old Security Context CTX_OLD, rather than simply 909 overwriting it to become CTX_NEW. This allows the peer to decrypt 910 late, still on-the-fly incoming messages protected with CTX_OLD. 912 When enforcing such policies, the following applies. 914 * Outgoing messages MUST be protected by using only CTX_NEW. 916 * Incoming messages MUST first be attempted to decrypt by using 917 CTX_NEW. If decryption fails, a second attempt can use CTX_OLD. 919 * When an amount of time defined by the policy has elapsed since the 920 establishment of CTX_NEW, the peer deletes CTX_OLD. 922 4.5. Discussion 924 KUDOS is intended to deprecate and replace the procedure defined in 925 Appendix B.2 of [RFC8613], as fundamentally achieving the same goal, 926 while displaying a number of improvements and advantages. 928 In particular, it is especially convenient for the handling of 929 failure events concerning the JRC node in 6TiSCH networks (see 930 Section 3). That is, among its intrinsic advantages compared to the 931 procedure defined in Appendix B.2 of [RFC8613], KUDOS preserves the 932 same ID Context value, when establishing a new OSCORE Security 933 Context. 935 Since the JRC uses ID Context values as identifiers of network nodes, 936 namely "pledge identifiers", the above implies that the JRC does not 937 have anymore to perform a mapping between a new, different ID Context 938 value and a certain pledge identifier (see Section 8.3.3 of 939 [RFC9031]). It follows that pledge identifiers can remain constant 940 once assigned, and thus ID Context values used as pledge identifiers 941 can be employed in the long-term as originally intended. 943 5. Security Considerations 945 This document mainly covers security considerations about using AEAD 946 keys in OSCORE and their usage limits, in addition to the security 947 considerations of [RFC8613]. 949 Depending on the specific key update procedure used to establish a 950 new OSCORE Security Context, the related security considerations also 951 apply. 953 TODO: Add more considerations. 955 6. IANA Considerations 957 This document has the following actions for IANA. 959 6.1. OSCORE Flag Bits Registry 961 IANA is asked to add the following entries to the "OSCORE Flag Bits" 962 registry within the "Constrained RESTful Environments (CoRE) 963 Parameters" registry group. 965 +----------+------------------+------------------------+-----------+ 966 | Bit | Name | Description | Reference | 967 | Position | | | | 968 +----------+------------------+------------------------+-----------+ 969 | 1 | Extension-1 Flag | Set to 1 if the OSCORE | [This | 970 | | | Option specifies a | Document] | 971 | | | second byte of OSCORE | | 972 | | | flag bits | | 973 +----------+------------------+------------------------+-----------+ 974 | 15 | ID Detail Flag | Set to 1 if the | [This | 975 | | | compressed COSE object | Document] | 976 | | | contains 'id detail' | | 977 +----------+------------------+------------------------+-----------+ 979 7. References 981 7.1. Normative References 983 [I-D.ietf-lake-edhoc] 984 Selander, G., Mattsson, J. P., and F. Palombini, 985 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 986 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20 987 October 2021, . 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, 992 DOI 10.17487/RFC2119, March 1997, 993 . 995 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 996 Application Protocol (CoAP)", RFC 7252, 997 DOI 10.17487/RFC7252, June 2014, 998 . 1000 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1001 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1002 May 2017, . 1004 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1005 "Object Security for Constrained RESTful Environments 1006 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1007 . 1009 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 1010 Representation (CBOR)", STD 94, RFC 8949, 1011 DOI 10.17487/RFC8949, December 2020, 1012 . 1014 7.2. Informative References 1016 [I-D.ietf-ace-oauth-authz] 1017 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1018 H. Tschofenig, "Authentication and Authorization for 1019 Constrained Environments (ACE) using the OAuth 2.0 1020 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1021 draft-ietf-ace-oauth-authz-45, 29 August 2021, 1022 . 1025 [I-D.ietf-ace-oscore-profile] 1026 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1027 "OSCORE Profile of the Authentication and Authorization 1028 for Constrained Environments Framework", Work in Progress, 1029 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 1030 2021, . 1033 [I-D.irtf-cfrg-aead-limits] 1034 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on 1035 AEAD Algorithms", Work in Progress, Internet-Draft, draft- 1036 irtf-cfrg-aead-limits-03, 12 July 2021, 1037 . 1040 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 1041 Technical Specification - Core, Approved Version 1.2, OMA- 1042 TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, 1043 . 1047 [LwM2M-Transport] 1048 Open Mobile Alliance, "Lightweight Machine to Machine 1049 Technical Specification - Transport Bindings, Approved 1050 Version 1.2, OMA-TS-LightweightM2M_Transport- 1051 V1_2-20201110-A", November 2020, 1052 . 1056 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1057 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1058 . 1060 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1061 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1062 Internet of Things (IoT): Problem Statement", RFC 7554, 1063 DOI 10.17487/RFC7554, May 2015, 1064 . 1066 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 1067 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 1068 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 1069 May 2017, . 1071 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1072 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1073 . 1075 [RFC9031] Vučinić, M., Ed., Simon, J., Pister, K., and M. 1076 Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", 1077 RFC 9031, DOI 10.17487/RFC9031, May 2021, 1078 . 1080 Acknowledgments 1082 The authors sincerely thank Christian Amsuess, John Mattsson and 1083 Goeran Selander for their feedback and comments. 1085 The work on this document has been partly supported by VINNOVA and 1086 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1087 (Grant agreement 952652). 1089 Authors' Addresses 1090 Rikard Höglund 1091 RISE AB 1092 Isafjordsgatan 22 1093 SE-16440 Stockholm Kista 1094 Sweden 1096 Email: rikard.hoglund@ri.se 1098 Marco Tiloca 1099 RISE AB 1100 Isafjordsgatan 22 1101 SE-16440 Stockholm Kista 1102 Sweden 1104 Email: marco.tiloca@ri.se