idnits 2.17.1 draft-hoeglund-core-oscore-key-limits-00.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 (February 19, 2021) is 1155 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-36 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-15 == Outdated reference: A later version (-23) exists of draft-ietf-lake-edhoc-03 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-40 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-aead-limits-01 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group R. Hoeglund 3 Internet-Draft M. Tiloca 4 Updates: 8613 (if approved) RISE AB 5 Intended status: Standards Track February 19, 2021 6 Expires: August 23, 2021 8 AEAD Key Usage Limits in OSCORE 9 draft-hoeglund-core-oscore-key-limits-00 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 peers using OSCORE must take these limits into 19 account and what steps they must take to preserve the security of 20 their communications. Therefore, this document updates RFC8613. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 23, 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Limits for 'q' and 'v' . . . . . . . . . . . . . . . . . 4 60 3. Additional Information in the Security Context . . . . . . . 4 61 4. OSCORE Messages Processing . . . . . . . . . . . . . . . . . 5 62 4.1. Protecting a Request or a Response . . . . . . . . . . . 5 63 4.2. Verifying a Request or a Response . . . . . . . . . . . . 6 64 5. Methods for Rekeying OSCORE . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Object Security for Constrained RESTful Environments (OSCORE) 76 [RFC8613] provides end-to-end protection of CoAP [RFC7252] messages 77 at the application-layer, ensuring message confidentiality and 78 integrity, replay protection, as well as binding of response to 79 request between a sender and a recipient. 81 In particular, OSCORE uses AEAD algorithms to provide confidentiality 82 and integrity of messages exchanged between two peers. Due to known 83 issues allowing forgery attacks against AEAD algorithms, limits 84 should be followed on the number of times a specific key is used to 85 perform encryption or decryption [I-D.irtf-cfrg-aead-limits]. 87 Should these limits be exceeded, an adversary may break the security 88 properties of the AEAD algorithm, such as message confidentiality and 89 integrity, e.g. by performing a message forgery attack. The original 90 OSCORE specification [RFC8613] does not consider such limits. 92 This document updates [RFC8613] and defines when a peer must stop 93 using an OSCORE Security Context shared with another peer, due to the 94 reached key usage limits. When this happens, the two peers have to 95 establish a new Security Context with new keying material, in order 96 to continue their secure communication with OSCORE. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 Readers are expected to be familiar with the terms and concepts 107 related to the CoAP [RFC7252] and OSCORE [RFC8613] protocols. 109 2. Problem Overview 111 The OSCORE security protocol [RFC8613] uses AEAD algorithms to 112 provide integrity and confidentiality of messages, as exchanged 113 between two peers sharing an OSCORE Security Context. 115 When processing messages with OSCORE, each peer should follow 116 specific limits as to the number of times it uses a specific key. 117 This applies separately to the Sender Key used to encrypt outgoing 118 messages, and to the Recipient Key used to decrypt and verify 119 incoming protected messages. 121 Exceeding these limits may allow an adversary to break the security 122 properties of the AEAD algorithm, such as message confidentiality and 123 integrity, e.g. by performing a message forgery attack. 125 The following refers to the two parameters 'q' and 'v' introduced in 126 [I-D.irtf-cfrg-aead-limits], to use when deploying an AEAD algorithm. 128 o 'q': this parameter has as value the number of messages protected 129 with a specific key, i.e. the number of times the AEAD algorithm 130 has been invoked to encrypt data with that key. 132 o 'v': this parameter has as value the number of alleged forgery 133 attempts that have been made against a specific key, i.e. the 134 amount of failed decryptions that has been done with the AEAD 135 algorithm for that key. 137 When a peer uses OSCORE: 139 o The key used to protect outgoing messages is its Sender Key, in 140 its Sender Context. 142 o The key used to decrypt and verify incoming messages is its 143 Recipient Key, in its Recipient Context. 145 Both keys are derived as part of the establishment of the OSCORE 146 Security Context, as defined in Section 3.2 of [RFC8613]. 148 As mentioned above, exceeding specific limits for the 'q' or 'v' 149 value can weaken the security properties of the AEAD algorithm used, 150 thus compromising secure communication requirements. 152 Therefore, in order to preserve the security of the used AEAD 153 algorithm, OSCORE has to observe limits for the 'q' and 'v' values, 154 throughout the lifetime of the used AEAD keys. 156 2.1. Limits for 'q' and 'v' 158 Recommendations for setting limits for the maximum 'q' and 'v' value 159 are defined in [I-D.irtf-cfrg-aead-limits]. 161 In particular, Figure 1 shows the limits given for AES-CCM-16-64-128, 162 which is the mandatory to implement AEAD algorithm for OSCORE. 164 q <= sqrt((p * 2^126) / l^2) 166 v * 2^64 + (2l * (v + q))^2 <= p * 2^128 168 Figure 1: AES-CCM-16-64-128 limits 170 Considering the values p_q = 2^-60 and p_v = 2^-57 defined in 171 [I-D.ietf-tls-dtls13], as well as l=1024, this gives the following 172 values for the limits of 'q' and 'v'. 174 q <= sqrt(((2^-60) * 2^126) / 1024^2) 176 q <= 2^23 178 v * 2^64 + (2*1024 * (v + 2^23))^2 <= 2^-57 * 2^128 180 v <= 112 182 3. Additional Information in the Security Context 184 In addition to what defined in Section 3.1 of [RFC8613], the OSCORE 185 Security Context MUST also include the following information. 187 The Sender Context is extended to include the following parameters. 189 o 'count_q': a non-negative integer counter, keeping track of the 190 current 'q' value for the Sender Key. At any time, 'count_q' has 191 as value the number of messages that have been encrypted using the 192 Sender Key. The value of 'count_q' is set to 0 when establishing 193 the Sender Context. 195 o 'limit_q': a non-negative integer, which specifies the highest 196 value that 'count_q' is allowed to reach, before stopping using 197 the Sender Key to process outgoing messages. 199 The value of 'limit_q' depends on the AEAD algorithm specified in 200 the Common Context, considering the properties of that algorithm. 201 The value of 'limit_q' is determined according to Section 3. 203 The Recipient Context is extended to include the following 204 parameters. 206 o 'count_v': a non-negative integer counter, keeping track of the 207 current 'v' value for the Recipient Key. At any time, 'count_v' 208 has as value the number of failed decryptions occurred on incoming 209 messages using the Recipient Key. The value of 'count_v' is set to 210 0 when establishing the Recipient Context. 212 o 'limit_v': a non-negative integer, which specifies the highest 213 value that 'count_v' is allowed to reach, before stopping using 214 the Recipient Key to process incoming messages. 216 The value of 'limit_v' depends on the AEAD algorithm specified in 217 the Common Context, considering the properties of that algorithm. 218 The value of 'limit_v' is determined according to Section 3. 220 4. OSCORE Messages Processing 222 In order to keep track of the 'q' and 'v' values and ensure that AEAD 223 keys are not used beyond reaching their limits, the processing of 224 OSCORE messages is extended as defined in this section. 226 In particular, the processing of OSCORE messages follows the steps 227 outlined in Section 8 of [RFC8613], with the additions defined below. 229 4.1. Protecting a Request or a Response 231 Before encrypting the COSE object using the Sender Key, the 'count_q' 232 counter MUST be incremented. 234 If 'count_q' exceeds the 'limit_q' limit, the message processing MUST 235 be aborted. From then on, the Sender Key MUST NOT be used to encrypt 236 further messages. 238 4.2. Verifying a Request or a Response 240 If the decryption and verification of the COSE object using the 241 Recipient Key fails, the 'count_v' counter MUST be incremented. 243 After 'count_v' has exceeded the 'limit_v' limit, incoming messages 244 MUST NOT be decrypted and verified using the Recipient Key, and their 245 processing MUST be aborted. 247 5. Methods for Rekeying OSCORE 249 Before the limit of 'q' or 'v' has been reached for an OSCORE 250 Security Context, the two peers have to establish a new OSCORE 251 Security Context, in order to continue using OSCORE for secure 252 communication. 254 In practice, the two peers have to establish new Sender and Recipient 255 Keys, as the keys actually used by the AEAD algorithm. When this 256 happens, both peers reset their 'count_q' and 'count_v' values to 0 257 (see Section 3). 259 Currently, a number of ways exist to accomplish this. 261 o The two peers can run the procedure defined in Appendix B.2 of 262 [RFC8613]. That is, the two peers exchange three or four 263 messages, protected with temporary Security Contexts adding 264 randomness to the ID Context. 266 As a result, the two peers establish a new OSCORE Security Context 267 with new ID Context, Sender Key and Recipient Key, while keeping 268 the same OSCORE Master Secret and OSCORE Master Salt from the old 269 OSCORE Security Context. 271 This procedure does not require any additional components to what 272 OSCORE already provides, and it does not provide perfect forward 273 secrecy. 275 o The two peers can run the OSCORE profile 276 [I-D.ietf-ace-oscore-profile] of the Authentication and 277 Authorization for Constrained Environments (ACE) Framework 278 [I-D.ietf-ace-oauth-authz]. 280 When a CoAP client uploads an Access Token to a CoAP server as an 281 access credential, the two peers also exchange two nonces. Then, 282 the two peers use the two nonces together with information 283 provided by the ACE Authorization Server that issued the Access 284 Token, in order to derive an OSCORE Security Context. 286 This procedure does not provide perfect forward secrecy. 288 o The two peers can run the EDHOC key exchange protocol based on 289 Diffie-Hellman and defined in [I-D.ietf-lake-edhoc], in order to 290 establish a pseudo-random key in a mutually authenticated way. 292 Then, the two peers can use the established pseudo-random key to 293 derive external application keys. This allows the two peers to 294 securely derive especially an OSCORE Master Secret and an OSCORE 295 Master Salt, from which an OSCORE Security Context can be 296 established. 298 This procedure additionally provides perfect forward secrecy. 300 Manually updating the OSCORE Security Context at the two peers should 301 be a last resort option, and it might often be not practical or 302 feasible. 304 It is RECOMMENDED that the peer initiating the rekeying procedure 305 starts it before reaching the 'q' or 'v' limits. Otherwise, the AEAD 306 keys possibly to be used during the rekeying procedure itself may 307 already be or become invalid before the rekeying is completed, which 308 may prevent a successful establishment of the new OSCORE Security 309 Context altogether. 311 6. Security Considerations 313 This document mainly covers security considerations about using AEAD 314 keys in OSCORE and their usage limits, in addition to the security 315 considerations of [RFC8613]. 317 Depending on the specific rekeying procedure used to establish a new 318 OSCORE Security Context, the related security considerations also 319 apply. 321 TODO: Add more considerations. 323 7. IANA Considerations 325 This document has no actions for IANA. 327 Acknowledgments 329 The authors sincerely thank Christian Amsuess, John Mattsson and 330 Goeran Selander for the initial discussions that allowed shaping this 331 document. 333 The work on this document has been partly supported by VINNOVA and 334 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 335 (Grant agreement 952652). 337 9. References 339 9.1. Normative References 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, 343 DOI 10.17487/RFC2119, March 1997, 344 . 346 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 347 Application Protocol (CoAP)", RFC 7252, 348 DOI 10.17487/RFC7252, June 2014, 349 . 351 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 352 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 353 May 2017, . 355 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 356 "Object Security for Constrained RESTful Environments 357 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 358 . 360 9.2. Informative References 362 [I-D.ietf-ace-oauth-authz] 363 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 364 H. Tschofenig, "Authentication and Authorization for 365 Constrained Environments (ACE) using the OAuth 2.0 366 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 367 (work in progress), November 2020. 369 [I-D.ietf-ace-oscore-profile] 370 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 371 "OSCORE Profile of the Authentication and Authorization 372 for Constrained Environments Framework", draft-ietf-ace- 373 oscore-profile-15 (work in progress), January 2021. 375 [I-D.ietf-lake-edhoc] 376 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 377 Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake- 378 edhoc-03 (work in progress), December 2020. 380 [I-D.ietf-tls-dtls13] 381 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 382 Datagram Transport Layer Security (DTLS) Protocol Version 383 1.3", draft-ietf-tls-dtls13-40 (work in progress), January 384 2021. 386 [I-D.irtf-cfrg-aead-limits] 387 Guenther, F., Thomson, M., and C. Wood, "Usage Limits on 388 AEAD Algorithms", draft-irtf-cfrg-aead-limits-01 (work in 389 progress), September 2020. 391 Authors' Addresses 393 Rikard Hoeglund 394 RISE AB 395 Isafjordsgatan 22 396 Kista SE-16440 Stockholm 397 Sweden 399 Email: rikard.hoglund@ri.se 401 Marco Tiloca 402 RISE AB 403 Isafjordsgatan 22 404 Kista SE-16440 Stockholm 405 Sweden 407 Email: marco.tiloca@ri.se