idnits 2.17.1 draft-hoeglund-core-oscore-key-limits-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(903): 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 3 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 (12 July 2021) is 1018 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 (-46) exists of draft-ietf-ace-oauth-authz-43 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-07 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-aead-limits-02 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 12 July 2021 6 Expires: 13 January 2022 8 Key Update for OSCORE 9 draft-hoeglund-core-oscore-key-limits-01 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 a lightweight method that two peers can use to update their 22 keying material and establish a new OSCORE Security Context. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 13 January 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. AEAD Key Usage Limits in OSCORE . . . . . . . . . . . . . . . 3 60 2.1. Problem Overview . . . . . . . . . . . . . . . . . . . . 3 61 2.1.1. Limits for 'q' and 'v' . . . . . . . . . . . . . . . 4 62 2.2. Additional Information in the Security Context . . . . . 6 63 2.2.1. Common Context . . . . . . . . . . . . . . . . . . . 6 64 2.2.2. Sender Context . . . . . . . . . . . . . . . . . . . 7 65 2.2.3. Recipient Context . . . . . . . . . . . . . . . . . . 7 66 2.3. OSCORE Messages Processing . . . . . . . . . . . . . . . 7 67 2.3.1. Protecting a Request or a Response . . . . . . . . . 8 68 2.3.2. Verifying a Request or a Response . . . . . . . . . . 8 69 2.4. Current methods for Rekeying OSCORE . . . . . . . . . . . 8 70 3. New Method for Rekeying OSCORE . . . . . . . . . . . . . . . 10 71 3.1. Extensions to the OSCORE Option . . . . . . . . . . . . . 10 72 3.2. Update Function . . . . . . . . . . . . . . . . . . . . . 11 73 3.3. Establishment of the New OSCORE Security Context . . . . 14 74 3.4. Retention Policies . . . . . . . . . . . . . . . . . . . 18 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 5.1. OSCORE Flag Bits Registry . . . . . . . . . . . . . . . . 19 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 6.1. Normative References . . . . . . . . . . . . . . . . . . 19 80 6.2. Informative References . . . . . . . . . . . . . . . . . 20 81 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 Object Security for Constrained RESTful Environments (OSCORE) 87 [RFC8613] provides end-to-end protection of CoAP [RFC7252] messages 88 at the application-layer, ensuring message confidentiality and 89 integrity, replay protection, as well as binding of response to 90 request between a sender and a recipient. 92 In particular, OSCORE uses AEAD algorithms to provide confidentiality 93 and integrity of messages exchanged between two peers. Due to known 94 issues allowing forgery attacks against AEAD algorithms, limits 95 should be followed on the number of times a specific key is used to 96 perform encryption or decryption [I-D.irtf-cfrg-aead-limits]. 98 Should these limits be exceeded, an adversary may break the security 99 properties of the AEAD algorithm, such as message confidentiality and 100 integrity, e.g. by performing a message forgery attack. The original 101 OSCORE specification [RFC8613] does not consider such limits. 103 This document updates [RFC8613] and defines when a peer must stop 104 using an OSCORE Security Context shared with another peer, due to the 105 reached key usage limits. When this happens, the two peers have to 106 establish a new Security Context with new keying material, in order 107 to continue their secure communication with OSCORE. 109 Furthermore, this document specifies a lightweight method that the 110 two peers can use in order to update their current keying material 111 and establish a new OSCORE Security Context. 113 1.1. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 Readers are expected to be familiar with the terms and concepts 122 related to the CoAP [RFC7252] and OSCORE [RFC8613] protocols. 124 2. AEAD Key Usage Limits in OSCORE 126 The following sections details how key usage limits for AEAD 127 algorithms must be considered when using OSCORE. It covers specific 128 limits for common AEAD algorithms used with OSCORE; necessary 129 additions to the OSCORE Security Context, updates to the OSCORE 130 message processing, and existing methods for rekeying OSCORE. 132 2.1. Problem Overview 134 The OSCORE security protocol [RFC8613] uses AEAD algorithms to 135 provide integrity and confidentiality of messages, as exchanged 136 between two peers sharing an OSCORE Security Context. 138 When processing messages with OSCORE, each peer should follow 139 specific limits as to the number of times it uses a specific key. 140 This applies separately to the Sender Key used to encrypt outgoing 141 messages, and to the Recipient Key used to decrypt and verify 142 incoming protected messages. 144 Exceeding these limits may allow an adversary to break the security 145 properties of the AEAD algorithm, such as message confidentiality and 146 integrity, e.g. by performing a message forgery attack. 148 The following refers to the two parameters 'q' and 'v' introduced in 149 [I-D.irtf-cfrg-aead-limits], to use when deploying an AEAD algorithm. 151 * 'q': this parameter has as value the number of messages protected 152 with a specific key, i.e. the number of times the AEAD algorithm 153 has been invoked to encrypt data with that key. 155 * 'v': this parameter has as value the number of alleged forgery 156 attempts that have been made against a specific key, i.e. the 157 amount of failed decryptions that has been done with the AEAD 158 algorithm for that key. 160 When a peer uses OSCORE: 162 * The key used to protect outgoing messages is its Sender Key, in 163 its Sender Context. 165 * The key used to decrypt and verify incoming messages is its 166 Recipient Key, in its Recipient Context. 168 Both keys are derived as part of the establishment of the OSCORE 169 Security Context, as defined in Section 3.2 of [RFC8613]. 171 As mentioned above, exceeding specific limits for the 'q' or 'v' 172 value can weaken the security properties of the AEAD algorithm used, 173 thus compromising secure communication requirements. 175 Therefore, in order to preserve the security of the used AEAD 176 algorithm, OSCORE has to observe limits for the 'q' and 'v' values, 177 throughout the lifetime of the used AEAD keys. 179 2.1.1. Limits for 'q' and 'v' 181 Formulas for calculating the security levels as Integrity Advantage 182 (IA) and Confidentiality Advantage (CA) probabilities, are presented 183 in [I-D.irtf-cfrg-aead-limits]. These formulas take as input 184 specific values for 'q' and 'v' (see section Section 2.1) and for 185 'l', i.e., the maximum length of each message (in cipher blocks). 187 For the algorithms that can be used as AEAD Algorithm for OSCORE 188 shows in Figure 1, the key property to achieve is having IA and CA 189 values which are no larger than p = 2^-64, which will ensure a safe 190 security level for the AEAD Algorithm. This can be entailed by using 191 the values q = 2^20, v = 2^20, and l = 2^8, that this document 192 recommends to use for these algorithms. 194 Figure 1 shows the resulting IA and CA probabilities enjoyed by the 195 considered algorithms, when taking the value of 'q', 'v' and 'l' 196 above as input to the formulas defined in 197 [I-D.irtf-cfrg-aead-limits]. 199 +------------------------+----------------+----------------+ 200 | Algorithm name | IA probability | CA probability | 201 |------------------------+----------------+----------------| 202 | AEAD_AES_128_CCM | 2^-68 | 2^-70 | 203 | AEAD_AES_128_GCM | 2^-99 | 2^-89 | 204 | AEAD_AES_256_GCM | 2^-99 | 2^-89 | 205 | AEAD_CHACHA20_POLY1305 | 2^-75 | - | 206 +------------------------+----------------+----------------+ 208 Figure 1: Probabilities for algorithms based on chosen q, v and l 209 values. 211 For the AEAD_AES_128_CCM_8 algorithm when used as AEAD Algorithm for 212 OSCORE, larger IA and CA values are achieved, depending on the value 213 of 'q', 'v' and 'l'. Figure 2 shows the resulting IA and CA 214 probabilities enjoyed by AEAD_AES_128_CCM_8, when taking different 215 values of 'q', 'v' and 'l' as input to the formulas defined in 216 [I-D.irtf-cfrg-aead-limits]. 218 As shown in Figure 2, it is especially possible to achieve the lowest 219 IA = 2^-54 and a good CA = 2^-70 by considering the largest possible 220 value of the (q, v, l) triplet equal to (2^20, 2^10, 2^8), while 221 still keeping a good security level. Note that the value of 'l' does 222 not impact on IA, while CA displays good values for every considered 223 value of 'l'. 225 When AEAD_AES_128_CCM_8 is used as AEAD Algorithm for OSCORE, this 226 document recommends to use the triplet (q, v, l) = (2^20, 2^10, 2^8) 227 and to never use a triplet (q, v, l) such that the resulting IA and 228 CA probabilities are higher than 2^-54. 230 +-----------------------+----------------+----------------+ 231 | 'q', 'v' and 'l' | IA probability | CA probability | 232 |-----------------------+----------------+----------------| 233 | q=2^20, v=2^20, l=2^8 | 2^-44 | 2^-70 | 234 | q=2^15, v=2^20, l=2^8 | 2^-44 | 2^-80 | 235 | q=2^10, v=2^20, l=2^8 | 2^-44 | 2^-90 | 236 | q=2^20, v=2^15, l=2^8 | 2^-49 | 2^-70 | 237 | q=2^15, v=2^15, l=2^8 | 2^-49 | 2^-80 | 238 | q=2^10, v=2^15, l=2^8 | 2^-49 | 2^-90 | 239 | q=2^20, v=2^10, l=2^8 | 2^-54 | 2^-70 | 240 | q=2^15, v=2^10, l=2^8 | 2^-54 | 2^-80 | 241 | q=2^10, v=2^10, l=2^8 | 2^-54 | 2^-90 | 242 |-----------------------+----------------+----------------| 243 | q=2^20, v=2^20, l=2^6 | 2^-44 | 2^-74 | 244 | q=2^15, v=2^20, l=2^6 | 2^-44 | 2^-84 | 245 | q=2^10, v=2^20, l=2^6 | 2^-44 | 2^-94 | 246 | q=2^20, v=2^15, l=2^6 | 2^-49 | 2^-74 | 247 | q=2^15, v=2^15, l=2^6 | 2^-49 | 2^-84 | 248 | q=2^10, v=2^15, l=2^6 | 2^-49 | 2^-94 | 249 | q=2^20, v=2^10, l=2^6 | 2^-54 | 2^-74 | 250 | q=2^15, v=2^10, l=2^6 | 2^-54 | 2^-84 | 251 | q=2^10, v=2^10, l=2^6 | 2^-54 | 2^-94 | 252 +-----------------------+----------------+----------------+ 254 Figure 2: Probabilities for AEAD_AES_128_CCM_8 based on chosen q, 255 v and l values. 257 2.2. Additional Information in the Security Context 259 In addition to what defined in Section 3.1 of [RFC8613], the OSCORE 260 Security Context MUST also include the following information. 262 2.2.1. Common Context 264 The Common Context is extended to include the following parameter. 266 * 'exp': with value the expiration time of the OSCORE Security 267 Context, as a non-negative integer. The parameter contains a 268 numeric value representing the number of seconds from 269 1970-01-01T00:00:00Z UTC until the specified UTC date/time, 270 ignoring leap seconds, analogous to what specified for NumericDate 271 in Section 2 of [RFC7519]. 273 At the time indicated in this field, a peer MUST stop using this 274 Security Context to process any incoming or outgoing message, and 275 is required to establish a new Security Context to continue 276 OSCORE-protected communications with the other peer. 278 2.2.2. Sender Context 280 The Sender Context is extended to include the following parameters. 282 * 'count_q': a non-negative integer counter, keeping track of the 283 current 'q' value for the Sender Key. At any time, 'count_q' has 284 as value the number of messages that have been encrypted using the 285 Sender Key. The value of 'count_q' is set to 0 when establishing 286 the Sender Context. 288 * 'limit_q': a non-negative integer, which specifies the highest 289 value that 'count_q' is allowed to reach, before stopping using 290 the Sender Key to process outgoing messages. 292 The value of 'limit_q' depends on the AEAD algorithm specified in 293 the Common Context, considering the properties of that algorithm. 294 The value of 'limit_q' is determined according to Section 2.1.1. 296 2.2.3. Recipient Context 298 The Recipient Context is extended to include the following 299 parameters. 301 * 'count_v': a non-negative integer counter, keeping track of the 302 current 'v' value for the Recipient Key. At any time, 'count_v' 303 has as value the number of failed decryptions occurred on incoming 304 messages using the Recipient Key. The value of 'count_v' is set to 305 0 when establishing the Recipient Context. 307 * 'limit_v': a non-negative integer, which specifies the highest 308 value that 'count_v' is allowed to reach, before stopping using 309 the Recipient Key to process incoming messages. 311 The value of 'limit_v' depends on the AEAD algorithm specified in 312 the Common Context, considering the properties of that algorithm. 313 The value of 'limit_v' is determined according to Section 2.1.1. 315 2.3. OSCORE Messages Processing 317 In order to keep track of the 'q' and 'v' values and ensure that AEAD 318 keys are not used beyond reaching their limits, the processing of 319 OSCORE messages is extended as defined in this section. 321 In particular, the processing of OSCORE messages follows the steps 322 outlined in Section 8 of [RFC8613], with the additions defined below. 324 2.3.1. Protecting a Request or a Response 326 Before encrypting the COSE object using the Sender Key, the 'count_q' 327 counter MUST be incremented. 329 If 'count_q' exceeds the 'limit_q' limit, the message processing MUST 330 be aborted. From then on, the Sender Key MUST NOT be used to encrypt 331 further messages. 333 2.3.2. Verifying a Request or a Response 335 If an incoming message is detected to be a replay (see Section 7.4 of 336 [RFC8613]), the 'count_v' counter MUST NOT be incremented. 338 If the decryption and verification of the COSE object using the 339 Recipient Key fails, the 'count_v' counter MUST be incremented. 341 After 'count_v' has exceeded the 'limit_v' limit, incoming messages 342 MUST NOT be decrypted and verified using the Recipient Key, and their 343 processing MUST be aborted. 345 2.4. Current methods for Rekeying OSCORE 347 Before the limit of 'q' or 'v' has been reached for an OSCORE 348 Security Context, the two peers have to establish a new OSCORE 349 Security Context, in order to continue using OSCORE for secure 350 communication. 352 In practice, the two peers have to establish new Sender and Recipient 353 Keys, as the keys actually used by the AEAD algorithm. When this 354 happens, both peers reset their 'count_q' and 'count_v' values to 0 355 (see Section 2.2). 357 Other specifications define a number of ways to accomplish this. 359 * The two peers can run the procedure defined in Appendix B.2 of 360 [RFC8613]. That is, the two peers exchange three or four 361 messages, protected with temporary Security Contexts adding 362 randomness to the ID Context. 364 As a result, the two peers establish a new OSCORE Security Context 365 with new ID Context, Sender Key and Recipient Key, while keeping 366 the same OSCORE Master Secret and OSCORE Master Salt from the old 367 OSCORE Security Context. 369 This procedure does not require any additional components to what 370 OSCORE already provides, and it does not provide perfect forward 371 secrecy. 373 * The two peers can run the OSCORE profile 374 [I-D.ietf-ace-oscore-profile] of the Authentication and 375 Authorization for Constrained Environments (ACE) Framework 376 [I-D.ietf-ace-oauth-authz]. 378 When a CoAP client uploads an Access Token to a CoAP server as an 379 access credential, the two peers also exchange two nonces. Then, 380 the two peers use the two nonces together with information 381 provided by the ACE Authorization Server that issued the Access 382 Token, in order to derive an OSCORE Security Context. 384 This procedure does not provide perfect forward secrecy. 386 * The two peers can run the EDHOC key exchange protocol based on 387 Diffie-Hellman and defined in [I-D.ietf-lake-edhoc], in order to 388 establish a pseudo-random key in a mutually authenticated way. 390 Then, the two peers can use the established pseudo-random key to 391 derive external application keys. This allows the two peers to 392 securely derive especially an OSCORE Master Secret and an OSCORE 393 Master Salt, from which an OSCORE Security Context can be 394 established. 396 This procedure additionally provides perfect forward secrecy. 398 * If one peer is acting as LwM2M Client and the other peer as LwM2M 399 Server, according to the OMA Lightweight Machine to Machine Core 400 specification [LwM2M], then the LwM2M Client peer may take the 401 initiative to bootstrap again with the LwM2M Bootstrap Server, and 402 receive again an OSCORE Security Context. Alternatively, the 403 LwM2M Server can instruct the LwM2M Client to initiate this 404 procedure. 406 If the OSCORE Security Context information on the LwM2M Bootstrap 407 Server has been updated, the LwM2M Client will thus receive a 408 fresh OSCORE Security Context to use with the LwM2M Server. 410 Manually updating the OSCORE Security Context at the two peers should 411 be a last resort option, and it might often be not practical or 412 feasible. 414 Even when any of the alternatives mentioned above is available, it is 415 RECOMMENDED that two OSCORE peers update their Security Context by 416 using the procedure defined in Section 3 of this document. 418 It is RECOMMENDED that the peer initiating the rekeying procedure 419 starts it before reaching the 'q' or 'v' limits. Otherwise, the AEAD 420 keys possibly to be used during the rekeying procedure itself may 421 already be or become invalid before the rekeying is completed, which 422 may prevent a successful establishment of the new OSCORE Security 423 Context altogether. 425 3. New Method for Rekeying OSCORE 427 This section defines a lightweight method that two OSCORE peers can 428 use to update their keying material and establish a new OSCORE 429 Security Context. 431 The key update procedure relies on the support function updateCtx() 432 defined in Section 3.2 and the message exchange defined in 433 Section 3.3. The following properties are fulfilled. 435 * The procedure can be initiated by either peer. In particular, the 436 client or the server may start the procedure by sending the first 437 rekeying message. 439 * The new OSCORE Security Context enjoys Perfect Forward Secrecy. 441 * The same ID Context value used in the old OSCORE Security Context 442 is preserved in the new Security Context. Furthermore, the ID 443 Context value never changes throughout the procedure. 445 * The procedure is robust against a peer rebooting, and it 446 especially avoids the reuse of AEAD (nonce, key) pairs. 448 * The procedure completes in one round trip. The two peers achieve 449 mutual proof-of-possession in the following exchange, which is 450 protected with the newly established OSCORE Security Context. 452 3.1. Extensions to the OSCORE Option 454 In order to support the message exchange for establishing a new 455 OSCORE Security Context as defined in Section 3.3, this document 456 extends the use of the OSCORE option originally defined in [RFC8613] 457 as follows. 459 * This document defines the usage of the seventh least significant 460 bit, called "Extension-1 Flag", in the first byte of the OSCORE 461 option containing the OSCORE flag bits. This flag bit is 462 specified in Section 5.1. 464 When the Extension-1 Flag is set to 1, the second byte of the 465 OSCORE option MUST include the set of OSCORE flag bits 8-15. 467 * This document defines the usage of the first least significant bit 468 "ID Detail Flag", 'd', in the second byte of the OSCORE option 469 containing the OSCORE flag bits. This flag bit is specified in 470 Section 5.1. 472 When it is set to 1, the compressed COSE object contains an 'id 473 detail', to be used for the key update procedure defined in 474 Section 3.3. In particular, the 1 byte following 'kid context' 475 (if any) encodes the length x of 'id detail', and the following x 476 bytes encode 'id detail'. 478 * The second-to-eighth least significant bits in the second byte of 479 the OSCORE option containing the OSCORE flag bits are reserved for 480 future use. These bits SHALL be set to zero when not in use. 481 According to this specification, if any of these bits are set to 482 1, the message is considered to be malformed and decompression 483 fails as specified in item 2 of Section 8.2 of [RFC8613]. 485 Figure 3 shows the OSCORE option value including also 'id detail'. 487 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 <----- n bytes -----> 488 +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ 489 |0|1|0|h|k| n | 0 | 0 | 0 | 0 | 0 | 0 | 0 | d | Partial IV (if any) | 490 +-+-+-+-+-+-+-+-+---+---+---+---+---+---+---+---+---------------------+ 492 <- 1 byte -> <----- s bytes ------> <- 1 byte -> <----- x bytes ----> 493 +------------+----------------------+---------------------------------+ 494 | s (if any) | kid context (if any) | x (if any) | id detail (if any) | 495 +------------+----------------------+------------+--------------------+ 497 +------------------+ 498 | kid (if any) ... | 499 +------------------+ 501 Figure 3: The OSCORE option value, including 'id detail' 503 3.2. Update Function 505 The updateCtx() function shown in Figure 4 takes as input a nonce N 506 as well as an OSCORE Security Context CTX_IN, and returns a new 507 OSCORE Security Context CTX_OUT. 509 First, the updateCtx() function derives the new values of the Master 510 Secret and Master Salt for CTX_OUT as follows. 512 * If the two peers established their original Security Context as a 513 result of running the EDHOC protocol [I-D.ietf-lake-edhoc], the 514 EDHOC key PRK_4x3m is updated using the EDHOC-KeyUpdate() 515 function, which takes N as input. Then, the EDHOC-Exporter() 516 function is used to derive the new values for the Master Secret 517 and Master Salt. The original Security Context is the Security 518 Context a peer had before the key update procedure was used for 519 the first time. 521 * If the two peers established their original Security Context 522 through other means, the new Master Secret is derived through an 523 HKDF-Expand() step, which takes as input N as well as the Master 524 Secret value from the Security Context CTX_IN. Instead, the new 525 Master Salt takes N as value. 527 In either case, the derivation of new values follows the same 528 approach used in TLS 1.3, which is also based on HKDF-Expand (see 529 Section 7.1 of [RFC8446]) and used for computing new keying material 530 in case of key update (see Section 4.6.3 of [RFC8446]). 532 After that, the new Master Secret and Master Salt parameters are used 533 to derive a new Security Context CTX_OUT as per Section 3.2 of 534 [RFC8613]. Any other parameter required for the derivation takes the 535 same value as in the Security Context CTX_IN. Finally, the function 536 returns the newly derived Security Context CTX_OUT. 538 updateCtx( N, CTX_IN ) { 540 CTX_OUT // The new Security Context 541 MSECRET_NEW // The new Master Secret 542 MSALT_NEW // The new Master Salt 544 if { 546 EDHOC-KeyUpdate( N ) 547 // This results in updating the key PRK_4x3m of the EDHOC session, 548 // i.e., PRK_4x3m = Extract( N, PRK_4x3m ) 550 MSECRET_NEW = EDHOC-Exporter( "OSCORE Master Secret", key_length ) 551 = EDHOC-KDF(PRK_4x3m, TH_4, "OSCORE Master Secret", key_length ) 553 MSALT_NEW = EDHOC-Exporter( "OSCORE Master Salt", salt_length ) 554 = EDHOC-KDF( PRK_4x3m, TH_4, "OSCORE Master Salt", salt_length ) 556 } 557 else { 558 Master Secret Length = < Size of CTX_IN.MasterSecret in bytes > 560 MSECRET_NEW = HKDF-Expand-Label(CTX_IN.MasterSecret, Label, 561 N, Master Secret Length) 562 = HKDF-Expand(CTX_IN.MasterSecret, HkdfLabel, 563 Master Secret Length) 565 MSALT_NEW = N; 566 } 568 < Derive CTX_OUT using MSECRET_NEW and MSALT_NEW, 569 together with other parameters from CTX_IN > 571 Return CTX_OUT; 573 } 575 Where HkdfLabel is defined as 577 struct { 578 uint16 length = Length; 579 opaque label<7..255> = "oscore " + Label; 580 opaque context<0..255> = Context; 581 } HkdfLabel; 583 Figure 4: Function for deriving a new OSCORE Security Context 585 3.3. Establishment of the New OSCORE Security Context 587 This section defines the actual message exchange performed by two 588 peers to update their OSCORE keying material. Before starting the 589 key update procedure, the two peers share the OSCORE Security Context 590 CTX_OLD. Once completed the key update procedure, the two peers 591 agree on a newly established OSCORE Security Context CTX_NEW. 593 In particular, each peer contributes by generating a fresh value R1 594 or R2, and providing it to the other peer. Their concatenation R1|R2 595 is used as input N by the updateCtx() function, in order to derive 596 the new OSCORE Security Context CTX_NEW. 598 Both in the client- and server-initiated version of the procedure: 600 * The initiator always offers the fresh value R1. 602 * The responder always offers the fresh value R2. 604 * The responder is always the first one deriving the new OSCORE 605 Security Context CTX_NEW. 607 * The initiator is always the first one achieving key confirmation, 608 hence able to safely discard the old OSCORE Security Context 609 CTX_OLD. 611 * Both the initiator and the responder use the same respective 612 OSCORE Sender ID and Recipient ID. Also, they both preserve and 613 use the same OSCORE ID Context from CTX_OLD. 615 Figure 5 shows the key update procedure with the client acting as 616 initiator. 618 Client Server 619 (initiator) (responder) 620 | | 621 Generate R1 | | 622 | | 623 CTX_1 = | | 624 updateCtx(R1, | | 625 CTX_OLD) | | 626 | | 627 | Request #1 | 628 Protect with CTX_1 |------------------->| 629 | OSCORE Option: | CTX_1 = 630 | ... | update(R1, 631 | d flag: 1 | CTX_OLD) 632 | ... | 633 | ID Detail: R1 | Verify with CTX_1 634 | ... | 635 | | Generate R2 636 | | 637 | | CTX_NEW = 638 | | update(R1|R2, 639 | | CTX_OLD) 640 | | 641 | Response #1 | 642 |<-------------------| Protect with CTX_NEW 643 CTX_NEW = | OSCORE Option: | 644 updateCtx(R1|R2, | ... | 645 CTX_OLD) | d flag: 1 | 646 | ... | 647 Verify with CTX_NEW | ID Detail: R1|R2 | 648 | ... | 649 Discard CTX_OLD | | 650 | | 652 // The actual key update ends here 654 // The two peers can use the new Security Context CTX_NEW 656 | | 657 | Request #2 | 658 Protect with CTX_NEW |------------------->| 659 | | Verify with CTX_NEW 660 | | 661 | | Discard CTX_OLD 662 | | 663 | Response #2 | 664 |<-------------------| Protect with CTX_NEW 665 Verify with CTX_NEW | | 666 | | 668 Figure 5: Procedure for Establishing a New Security Context 669 (Client-initiated) 671 First, the client generates a random value R1 and uses it together 672 with the old Security Context CTX_OLD to derive a temporary Security 673 Context CTX_1. Then, the client sends a request to the server, 674 protected with the Security Context CTX_1. In particular, the 675 request has the 'd' flag bit set to 1 and specifies R1 as 'id detail' 676 (see Section 3.1). 678 Upon receiving the request, the server derives the temporary Security 679 Context CTX_1, by using the value R1 retrieved from the request and 680 the old Security Context CTX_OLD. Then, the server verifies the 681 request by using the Security Context CTX_1. 683 After that, the server generates a random value R2 and uses the 684 concatenation R1|R2 together with the old Security Context CTX_OLD to 685 derive the new Security Context CTX_NEW. Then, the server, sends a 686 response to the client, protected with the new Security Context 687 CTX_NEW. In particular, the response has the 'd' flag bit set to 1 688 and specifies R1|R2 as 'id detail'. 690 Upon receiving the response, the client retrieves the value R1|R2 691 from the response, and verifies that R1 coincides with the value R1 692 specified in the previously sent request. If so, the client derives 693 the new Security Context CTX_NEW, by using the value R1|R2 retrieved 694 from the response and the old Security Context CTX_OLD. Finally, the 695 client verifies the response by using the Security Context CTX_NEW 696 and deletes the old Security Context CTX_OLD. 698 After that, the client can send a new request protected with the new 699 Security Context CTX_NEW. When successfully verifying the request 700 using the Security Context CTX_NEW, the server deletes the old 701 Security Context CTX_OLD and can reply with a response protected with 702 the new Security Context CTX_NEW. 704 From then on, the two peers can protect their message exchanges by 705 using the new Security Context CTX_NEW. 707 Figure 6 shows the key update procedure with the server acting as 708 initiator. 710 Client Server 711 (responder) (initiator) 712 | | 713 | Request #1 | 714 Protect with CTX_OLD |------------------->| 715 | | Verify with CTX_OLD 716 | | 717 | | Generate R1 718 | | 719 | | CTX_1 = 720 | | updateCtx(R1, 721 | | CTX_OLD) 722 | | 723 | Response #1 | 724 |<-------------------| Protect with CTX_1 725 CTX_1 = | OSCORE Option: | 726 updateCtx(R1, | ... | 727 CTX_OLD) | d flag: 1 | 728 | ... | 729 Verify with CTX_1 | ID Detail: R1 | 730 | ... | 731 Generate R2 | | 732 | | 733 CTX_NEW = | | 734 updateCtx(R1|R2, | | 735 CTX_OLD) | | 736 | | 737 | Request #2 | 738 Protect with CTX_NEW |------------------->| 739 | OSCORE Option: | CTX_NEW = 740 | ... | updateCtx(R1|R2, 741 | d flag: 1 | CTX_OLD) 742 | ... | 743 | ID Detail: R1|R2 | Verify with CTX_NEW 744 | ... | 745 | | Discard CTX_OLD 746 | | 748 // The actual key update ends here 750 // The two peers can use the new Security Context CTX_NEW 752 | Response #2 | 753 |<-------------------| Protect with CTX_NEW 754 Verify with CTX_NEW | | 755 | | 756 Discard CTX_OLD | | 757 | | 759 Figure 6: Procedure for Establishing a New Security Context 760 (Server-initiated) 762 First, the client sends a normal request to the server, protected 763 with the old Security Context CTX_OLD. 765 Upon receiving the request and after having verified it with the old 766 Security Context CTX_OLD as usual, the server generates a random 767 value R1 and uses it together with the old Security Context CTX_OLD 768 to derive a temporary Security Context CTX_1. Then, the server sends 769 a response to the client, protected with the Security Context CTX_1. 770 In particular, the request has the 'd' flag bit set to 1 and 771 specifies R1 as 'id detail' (see Section 3.1). 773 Upon receiving the response, the client derives the temporary 774 Security Context CTX_1, by using the value R1 retrieved from the 775 response and the old Security Context CTX_OLD. Then, the client 776 verifies the response by using the Security Context CTX_1. 778 After that, the client generates a random value R2 and uses the 779 concatenation R1|R2 together with the old Security Context CTX_OLD to 780 derive the new Security Context CTX_NEW. Then, the client, sends a 781 request to the server, protected with the new Security Context 782 CTX_NEW. In particular, the request has the 'd' flag bit set to 1 783 and specifies R1|R2 as 'id detail'. 785 Upon receiving the request, the server retrieves the value R1|R2 from 786 the request, and verifies that R1 coincides with the value R1 787 specified in the previously sent response. If so, the server derives 788 the new Security Context CTX_NEW, by using the value R1|R2 retrieved 789 from the request and the old Security Context CTX_OLD. Finally, the 790 server verifies the request by using the Security Context CTX_NEW and 791 deletes the old Security Context CTX_OLD. 793 After that, the client can send a response protected with the new 794 Security Context CTX_NEW. When successfully verifying the response 795 using the Security Context CTX_NEW, the client deletes the old 796 Security Context CTX_OLD. 798 From then on, the two peers can protect their message exchanges by 799 using the new Security Context CTX_NEW. 801 3.4. Retention Policies 803 Applications MAY define policies that allows a peer to also 804 temporarily keep the old Security Context CTX_OLD, rather than simply 805 overwriting it to become CTX_NEW. This allows the peer to decrypt 806 late, still on-the-fly incoming messages protected with CTX_OLD. 808 When enforcing such policies, the following applies. 810 * Outgoing messages MUST be protected by using only CTX_NEW. 812 * Incoming messages MUST first be attempted to decrypt by using 813 CTX_NEW. If decryption fails, a second attempt can use CTX_OLD. 815 * When an amount of time defined by the policy has elapsed since the 816 establishment of CTX_NEW, the peer deletes CTX_OLD. 818 4. Security Considerations 820 This document mainly covers security considerations about using AEAD 821 keys in OSCORE and their usage limits, in addition to the security 822 considerations of [RFC8613]. 824 Depending on the specific rekeying procedure used to establish a new 825 OSCORE Security Context, the related security considerations also 826 apply. 828 TODO: Add more considerations. 830 5. IANA Considerations 832 This document has the following actions for IANA. 834 5.1. OSCORE Flag Bits Registry 836 IANA is asked to add the following value entries to the "OSCORE Flag 837 Bits" subregistry as part of the "CoRE Parameters" registry. 839 +----------+------------------+------------------------+-----------+ 840 | Bit | Name | Description | Reference | 841 | Position | | | | 842 +----------+------------------+------------------------+-----------+ 843 | 1 | Extension-1 Flag | Set to 1 if the OSCORE | [This | 844 | | | Option specifies a | Document] | 845 | | | second byte of OSCORE | | 846 | | | flag bits | | 847 +----------+------------------+------------------------+-----------+ 848 | 15 | ID Detail Flag | Set to 1 if the | [This | 849 | | | compressed COSE object | Document] | 850 | | | contains 'id detail' | | 851 +----------+------------------+------------------------+-----------+ 853 6. References 855 6.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, 859 DOI 10.17487/RFC2119, March 1997, 860 . 862 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 863 Application Protocol (CoAP)", RFC 7252, 864 DOI 10.17487/RFC7252, June 2014, 865 . 867 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 868 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 869 May 2017, . 871 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 872 "Object Security for Constrained RESTful Environments 873 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 874 . 876 6.2. Informative References 878 [I-D.ietf-ace-oauth-authz] 879 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 880 H. Tschofenig, "Authentication and Authorization for 881 Constrained Environments (ACE) using the OAuth 2.0 882 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 883 draft-ietf-ace-oauth-authz-43, 10 July 2021, 884 . 887 [I-D.ietf-ace-oscore-profile] 888 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 889 "OSCORE Profile of the Authentication and Authorization 890 for Constrained Environments Framework", Work in Progress, 891 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 892 2021, . 895 [I-D.ietf-lake-edhoc] 896 Selander, G., Mattsson, J. P., and F. Palombini, 897 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in 898 Progress, Internet-Draft, draft-ietf-lake-edhoc-07, 24 May 899 2021, . 902 [I-D.irtf-cfrg-aead-limits] 903 Günther, F., Thomson, M., and C. A. Wood, "Usage Limits on 904 AEAD Algorithms", Work in Progress, Internet-Draft, draft- 905 irtf-cfrg-aead-limits-02, 22 February 2021, 906 . 909 [LwM2M] Open Mobile Alliance, "Lightweight Machine to Machine 910 Technical Specification - Core, Approved Version 1.2, OMA- 911 TS-LightweightM2M_Core-V1_2-20201110-A", November 2020, 912 . 916 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 917 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 918 . 920 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 921 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 922 . 924 Acknowledgments 926 The authors sincerely thank Christian Amsuess, John Mattsson and 927 Goeran Selander for the initial discussions that allowed shaping this 928 document. 930 The work on this document has been partly supported by VINNOVA and 931 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 932 (Grant agreement 952652). 934 Authors' Addresses 936 Rikard Höglund 937 RISE AB 938 Isafjordsgatan 22 939 SE-16440 Stockholm Kista 940 Sweden 942 Email: rikard.hoglund@ri.se 944 Marco Tiloca 945 RISE AB 946 Isafjordsgatan 22 947 SE-16440 Stockholm Kista 948 Sweden 950 Email: marco.tiloca@ri.se