idnits 2.17.00 (12 Aug 2021) /tmp/idnits52021/draft-ietf-lake-reqs-04.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 (8 June 2020) is 705 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: draft-ietf-6tisch-minimal-security has been published as RFC 9031 == Outdated reference: draft-ietf-lpwan-coap-static-context-hc has been published as RFC 8824 == Outdated reference: A later version (-08) exists of draft-ietf-cose-x509-06 == Outdated reference: draft-ietf-core-echo-request-tag has been published as RFC 9175 == Outdated reference: draft-irtf-cfrg-randomness-improvements has been published as RFC 8937 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Vucinic 3 Internet-Draft Inria 4 Intended status: Informational G. Selander 5 Expires: 10 December 2020 J. Mattsson 6 Ericsson AB 7 D. Garcia 8 Odin Solutions S.L. 9 8 June 2020 11 Requirements for a Lightweight AKE for OSCORE 12 draft-ietf-lake-reqs-04 14 Abstract 16 This document compiles the requirements for a lightweight 17 authenticated key exchange protocol for OSCORE. This draft has 18 completed a working group last call (WGLC) in the LAKE working group. 19 Post-WGLC, the requirements are considered sufficiently stable for 20 the working group to proceed with its work. It is not currently 21 planned to publish this draft as an RFC. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 10 December 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. AKE for OSCORE . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.2.1. Initial Focus . . . . . . . . . . . . . . . . . . . . 6 61 2.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 7 62 2.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 8 63 2.5. Cryptographic Agility and Negotiation Integrity . . . . . 8 64 2.6. Cryptographic Strength . . . . . . . . . . . . . . . . . 9 65 2.7. Identity Protection . . . . . . . . . . . . . . . . . . . 9 66 2.8. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 10 67 2.9. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 68 2.10. Availability . . . . . . . . . . . . . . . . . . . . . . 11 69 2.11. Lightweight . . . . . . . . . . . . . . . . . . . . . . . 11 70 2.11.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 13 71 2.11.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . 15 72 2.11.3. NB-IoT . . . . . . . . . . . . . . . . . . . . . . . 16 73 2.11.4. Discussion and Summary of Benchmarks . . . . . . . . 18 74 2.11.5. AKE frequency . . . . . . . . . . . . . . . . . . . 20 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 21 76 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Informative References . . . . . . . . . . . . . . . . . . . . . 21 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 82 1. Introduction 84 OSCORE [RFC8613] is a lightweight communication security protocol 85 providing end-to-end security on application layer for constrained 86 IoT settings (cf. [RFC7228]). OSCORE lacks a matching authenticated 87 key exchange protocol (AKE). The intention with the LAKE WG 88 [LAKE-WG] is to create a simple yet secure AKE for implementation in 89 embedded devices supporting OSCORE. 91 To ensure that the AKE is efficient for the expected applications of 92 OSCORE, we list the relevant public specifications of technologies 93 where OSCORE is included: 95 * The IETF 6TiSCH WG charter identifies the need to "secur[e] the 96 join process and mak[e] that fit within the constraints of high 97 latency, low throughput and small frame sizes that characterize 98 IEEE802.15.4 TSCH". OSCORE protects the join protocol as 99 described in 6TiSCH Minimal Security 100 [I-D.ietf-6tisch-minimal-security]. 102 * The IETF LPWAN WG charter identifies the need to improve the 103 transport capabilities of LPWA networks such as NB-IoT and LoRa 104 whose "common traits include ... frame sizes ... [on] the order of 105 tens of bytes transmitted a few times per day at ultra-low 106 speeds". The application of OSCORE is described in 107 [I-D.ietf-lpwan-coap-static-context-hc]. 109 * OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two 110 challenging radio technologies where OSCORE is planned to be 111 deployed: LoRaWAN and NB-IoT. 113 * Open Connectivity Foundation (OCF) plans to use OSCORE for end-to- 114 end security of unicast messages [OCF]. 116 This document compiles the requirements for the AKE for OSCORE. It 117 summarizes the security requirements that are expected from such an 118 AKE, as well as the main characteristics of the environments where 119 the solution is envisioned to be deployed. The solution will 120 presumably be useful in other scenarios as well since a low security 121 overhead improves the overall performance. 123 2. Problem description 125 2.1. AKE for OSCORE 127 The rationale for designing this protocol is that OSCORE is lacking a 128 matching AKE. OSCORE was designed for lightweight RESTful operations 129 for example by minimizing the overhead, and applying the protection 130 to the application layer, thereby limiting the data being encrypted 131 and integrity protected for the other endpoint. Moreover, OSCORE was 132 tailored for use with lightweight primitives that are likely to be 133 implemented in the device, specifically CoAP [RFC7252], CBOR 134 [RFC7049] and COSE [RFC8152]. The same properties should apply to 135 the AKE. 137 In order to be suitable for OSCORE, at the end of the AKE protocol 138 run the two parties must agree on (see Section 3.2 of [RFC8613]): 140 * A shared secret (OSCORE Master Secret) with Perfect Forward 141 Secrecy (PFS, see Section 2.4) and a good amount of randomness. 142 (The term "good amount of randomness" is borrowed from [HKDF] to 143 signify not necessarily uniformly distributed randomness.) 145 * OSCORE Sender IDs of peer endpoints, arbitrarily short. 147 - Sender IDs are expected to be unique for a given Master Secret, 148 more precisely the quartet (Master Secret, Master Salt, ID 149 Context, Sender ID) must be unique, see Section 3.3. of 150 [RFC8613]. 152 * COSE algorithms to use with OSCORE 154 COSE provides the crypto primitives for OSCORE. The AKE shall 155 specify how it provides COSE algorithms to OSCORE. It is strongly 156 recommended that COSE is reused by the AKE, for identification of 157 credentials and algorithms, as extension point for new schemes, and 158 to avoid duplicated implementation of crypto wrapper. 160 The AKE cannot rely on messages being exchanged in both directions 161 after the AKE has completed, because CoAP/OSCORE requests may not 162 have a response [RFC7967]. Furthermore, there is no assumption of 163 dependence between CoAP client/server and AKE initiator/responder 164 roles, and an OSCORE context may be used with CoAP client and server 165 roles interchanged as is done, for example, in [LwM2M]. 167 Moreover, the AKE must support transport over CoAP. When transported 168 over CoAP, the AKE must support the traversal of CoAP intermediaries, 169 as required by the 6TiSCH network formation setting 170 [I-D.ietf-6tisch-minimal-security]. 172 Since the AKE messages most commonly will be encapsulated in CoAP, 173 the AKE must not duplicate functionality provided by CoAP, or at 174 least not duplicate functionality in such a way that it adds non- 175 negligible extra costs in terms of code size, code maintenance, etc. 176 It is therefore assumed that the AKE is being transported in a 177 protocol that provides reliable transport, that can preserve packet 178 ordering and handle message duplication [RFC7252], that can perform 179 fragmentation [RFC7959] and protect against denial of service attacks 180 as provided by the CoAP Echo option [I-D.ietf-core-echo-request-tag]. 182 The AKE may use other transport than CoAP. In this case the 183 underlying layers must correspondingly handle message loss, 184 reordering, message duplication, fragmentation, and denial of service 185 protection. 187 2.2. Credentials 189 IoT deployments differ from one another in terms of what credentials 190 can be supported. Currently many systems use pre-shared keys (PSKs) 191 provisioned out of band, for various reasons. PSKs are sometimes 192 used in a first deployment because of their perceived simplicity. 193 The use of PSKs allows for protection of communication without major 194 additional security processing, and also enables the use of symmetric 195 crypto algorithms only, reducing the implementation and computational 196 effort in the endpoints. 198 However, PSK-based provisioning has inherent weaknesses. There has 199 been reports of massive breaches of PSK provisioning systems 200 [massive-breach], and as many systems use PSKs without Perfect 201 Forward Secrecy (PFS, see Section 2.4) they are vulnerable to passive 202 pervasive monitoring. The security of these systems can be improved 203 by adding PFS through an AKE authenticated by the provisioned PSK. 205 Shared keys can alternatively be established in the endpoints using 206 an AKE protocol authenticated with asymmetric public keys instead of 207 symmetric secret keys. Raw public keys (RPK) can be provisioned with 208 the same scheme as PSKs, which allows for a more relaxed trust model 209 since RPKs need not be secret. The corresponding private keys are 210 assumed to be provisioned to the party being authenticated beforehand 211 (e.g. in factory or generated on-board). 213 As a third option, by using a public key infrastructure and running 214 an asymmetric key AKE with public key certificates instead of RPKs, 215 key provisioning can be omitted, leading to a more automated ("zero- 216 touch") bootstrapping procedure. The root CA keys are assumed to be 217 provisioned beforehand. Public key certificates are important for 218 several IoT settings, e.g., facility management with a large number 219 of devices from many different manufacturers. 221 These steps provide an example of a migration path in limited scoped 222 steps from simple to more robust security bootstrapping and 223 provisioning schemes where each step improves the overall security 224 and/or simplicity of deployment of the IoT system, although not all 225 steps are necessarily feasible for the most constrained settings. 227 In order to allow for these different schemes, the AKE must support 228 PSK- (shared between two nodes), RPK- and certificate-based 229 authentication. These are also the schemes for which CoAP is 230 designed (see Section 9 of [RFC7252]). 232 Multiple public key authentication credential types may need to be 233 supported for RPK and certificate-based authentication. In case of a 234 Diffie-Hellman key exchange both the use of signature based public 235 keys (for compatibility with existing ecosystem) and static DH public 236 keys (for reduced message size) is expected. 238 To further minimize the bandwidth consumption it is required to 239 support transporting certificates and raw public keys by reference 240 rather than by value. Considering the wide variety of deployments, 241 the AKE must support different schemes for transporting and 242 identifying credentials. While there are many existing mechanisms 243 for doing so, ranging from PSK to raw public key by reference to 244 x5chain of in-band certificates [I-D.ietf-cose-x509], what is 245 appropriate for a given deployment will depend on the nature of that 246 deployment. In order to provide a clear initial effort, 247 Section 2.2.1 lists a set of credential types of immediate relevance; 248 the mechanism for selecting credential scheme is presumed to enable 249 future extensibility if needed. 251 The use of RPKs may be appropriate for the authentication of the AKE 252 initiator but not for the AKE responder. The AKE must support 253 different credentials for authentication in different directions of 254 the AKE run, e.g. certificate-based authentication for the initiating 255 endpoint and RPK-based authentication for the responding endpoint. 257 Assuming that both signature public keys and static DH public keys 258 are in use, then also the case of mixed credentials need to be 259 supported with one endpoint using a static DH public key and the 260 other using a signature public key. The AKE shall support 261 negotiation of public key credential mix and that both initiator and 262 responder can verify the variant that was executed. 264 2.2.1. Initial Focus 266 As illustrated above, the setting is much more diverse in terms of 267 credentials and trust anchors than that of the unconstrained web. In 268 order to deliver a timely result, there is a need to initially focus 269 on what is considered most important at the time of writing: RPK (by 270 reference and value) and certificate by reference. Information about 271 validity of a certificate may be omitted from the AKE if available 272 over unconstrained links. The case of transporting certificate 273 validation information over the AKE may be specified in the initial 274 phase if there is a lightweight solution that matches existing 275 standards and tools. 277 A subsequent extension beyond the initial focus may be inevitable to 278 maintain a homogenous deployment without having to implement a mix of 279 AKE protocols, for example, to support the migration path described 280 above. The AKE needs to make clear the scope of cases analysed in 281 the initial phase, and that a new analysis is required for additional 282 cases. 284 The initial scope as described in this subsection does not cover all 285 credentials as detailed previously in Section 2.2: an AKE which is 286 extensible but does not include PSK ECDHE would be conformant with 287 the requirements for the initial scope. A solution to the 288 requirements for the initial scope is intended to be a deliverable of 289 the LAKE WG. 291 2.3. Mutual Authentication 293 The AKE must provide mutual authentication during the protocol run. 294 At the end of the AKE protocol, each endpoint shall have freshly 295 authenticated the other's credential. In particular, both endpoints 296 must agree on a fresh session identifier, and the roles and 297 credentials of both endpoints. 299 Since the protocol may be initiated by different endpoints, it shall 300 not be necessary to determine beforehand which endpoint takes the 301 role of initiator of the AKE. 303 The mutual authentication guarantees of the AKE shall at least 304 guarantee the following properties: 306 * The AKE shall provide Key Compromise Impersonation (KCI) 307 resistance [KCI]. 309 * The AKE shall protect against identity misbinding attacks 310 [Misbinding]. Note that the identity may be directly related to a 311 public key such as for example the public key itself, a hash of 312 the public key, or data unrelated to a key. 314 * The AKE shall protect against reflection attacks, but need not 315 protect against attacks when more than two parties legitimately 316 share keys (cf. the Selfie attack on TLS 1.3 [Selfie]) as that 317 setting is out of scope. 319 Replayed messages shall not affect the security of an AKE session. 321 As often is the case, it is expected that an AKE fulfilling these 322 goals would have at least three flights of messages (with each flight 323 potentially consisting of one or more messages, depending on the AKE 324 design and the mapping to OSCORE). 326 2.4. Confidentiality 328 The shared secret established by the AKE must be known only to the 329 two authenticated endpoints. 331 A passive network attacker should never learn any session keys, even 332 if it knows both endpoints' long-term keys. 334 An active attacker who has compromised the initiator or responder 335 credential shall still not be able to compute past session keys 336 (Perfect Forward Secrecy, PFS). These properties can be achieved, 337 e.g., with an ephemeral Diffie-Hellman key exchange. 339 PFS may also be achieved in other ways, for example, using hash-based 340 ratcheting or with a nonce exchange followed by appropriately derived 341 new session keys provided that state can be kept in the form of a 342 session counter. Note that OSCORE specifies a method for session key 343 update involving a nonce exchange (see Appendix B in [RFC8613]). 345 The AKE shall provide a mechanism to use the output of one handshake 346 to optimize future handshakes, e.g., by generating keying material 347 which can be used to authenticate a future handshake, thus avoiding 348 the need for public key authentication in that handshake. 350 The AKE should give recommendations for frequency of re-keying 351 potentially dependent on the amount of data. 353 To mitigate against bad random number generators the AKE shall 354 provide recommendations for randomness, for example to use 355 [I-D.irtf-cfrg-randomness-improvements]. 357 2.5. Cryptographic Agility and Negotiation Integrity 359 Motivated by long deployment lifetimes, the AKE is required to 360 support cryptographic agility, including the modularity of COSE 361 crypto algorithms and negotiation of preferred crypto algorithms for 362 OSCORE and the AKE. 364 * The protocol shall support both pre-shared key and asymmetric key 365 authentication. PAKE, post-quantum and "hybrid" (simultaneously 366 more than one) key exchange is out of scope, but may be supported 367 in a later version. 369 * The protocol shall allow negotiation of elliptic curves for 370 Diffie-Hellman operations and signature-based authentication. 372 * The AKE shall support negotiation of all COSE algorithms 373 [IANA-COSE-Algorithms] to be used in OSCORE. The AKE shall 374 support negotiation of algorithms used in the AKE. It is strongly 375 recommended that the AKE algorithms are identified using 376 [IANA-COSE-Algorithms] to reduce unnecessary complexity of a 377 combined OSCORE/AKE implementation. 379 * A successful negotiation shall result in the most preferred 380 algorithms of one of the parties which are supported by the other. 382 * The AKE may choose different sets of symmetric crypto algorithms 383 (AEAD, MAC, etc.) for AKE and for OSCORE. In particular, the 384 length of the MAC for the AKE may be required to be larger than 385 for OSCORE. 387 The AKE negotiation must provide strong integrity guarantees against 388 active attackers. At the end of the AKE protocol, both endpoints 389 must agree on both the crypto algorithms that were proposed and those 390 that were chosen. In particular, the protocol must protect against 391 downgrade attacks. 393 2.6. Cryptographic Strength 395 The AKE shall establish a key with a target security level 396 [keylength] of >= 127 bits. This level was chosen to include X25519 397 and applies to the strength of authentication, the established keys, 398 and the protection for the negotiation of all cryptographic 399 parameters. 401 2.7. Identity Protection 403 In general, it is necessary to transport identities as part of the 404 AKE run in order to provide authentication of an entity not 405 identified beforehand. In the case of constrained devices, the 406 identity may contain sensitive information on the manufacturer of the 407 device, the batch, default firmware version, etc. Protecting 408 identifying information from passive and active attacks is important 409 from a privacy point of view, but needs to be balanced with the other 410 requirements, including security and lightweightness. 412 In the case of public key identities, the AKE is required to protect 413 the identity of one of the peers against active attackers and the 414 identity of the other peer against passive attackers. SIGMA-I and 415 SIGMA-R differ in this respect. SIGMA-I protects the identity of the 416 initiator against active attackers and the identity of the responder 417 against passive attackers. For SIGMA-R, the properties of the roles 418 are reversed at the cost of an additional flight. 420 It is not required to protect the PSK identifier, and it may thus be 421 sent in the first flight. Protection of PSK identifier in many cases 422 require extra flights of the AKE. 424 Other identifying information may also need to be transported in 425 plain text, for example, identifiers to allow correlation between AKE 426 messages, and cipher suites. Mechanisms to encrypt these kind of 427 parameters, such as using pre-configured public keys typically adds 428 to message overhead. 430 2.8. Auxiliary Data 432 In order to reduce round trips and the number of flights, and in some 433 cases also streamline processing, certain security features may be 434 integrated into the AKE by transporting "auxiliary data" together 435 with the AKE messages. 437 One example is the transport of third-party authorization information 438 from initiator to responder or vice versa. Such a scheme could 439 enable the party receiving the authorization information to make a 440 decision about whether the party being authenticated is also 441 authorized before the protocol is completed, and if not then 442 discontinue the protocol before it is complete, thereby saving time, 443 message processing and data transmission. 445 Another, orthogonal, example is the embedding of a certificate 446 enrolment request or a newly issued certificate in the AKE. 448 For example, the auxiliary data in the first two messages of the AKE 449 may transport authorization related information as in 450 [I-D.selander-ace-ake-authz] followed by a Certificate Signing 451 Request (CSR) in the auxiliary data of the third message. 453 The AKE must support the transport of such auxiliary data together 454 with the protocol messages. The auxiliary data field must not 455 contain data that violates the AKE security properties. The 456 auxiliary data field must only be used with security analysed 457 protocols. 459 The auxiliary data may contain privacy sensitive information. The 460 auxiliary data must be protected to the same level as AKE data in the 461 same flight. For example, for a SIGMA-I AKE it is expected that the 462 3 flights will provide the following protection of the auxiliary 463 data: 465 * Auxiliary data in the first flight is unprotected 466 * Auxiliary data in the second flight is confidentiality protected 467 against passive attackers and integrity protected against active 468 attackers 470 * Auxiliary data in the third flight is confidentiality and 471 integrity protected against active attackers 473 2.9. Extensibility 475 It is desirable that the AKE supports some kind of extensibility, in 476 particular, the ability to later include new AKE modes such as PAKE 477 support. COSE provides an extension mechanism for new algorithms, 478 new certificate formats, ways to identify credentials, etc. 480 The main objective with this work is to create a simple yet secure 481 AKE. The AKE should avoid having multiple ways to express the same 482 thing. If the underlying encodings offered by CBOR offer multiple 483 possibility the AKE should be strongly opinionated, and clearly 484 specify which one will be used. 486 While remaining extensible, the AKE should avoid optional mechanisms 487 which introduce code paths that are less well tested. 489 The AKE should avoid mechanisms where an initiator takes a guess at 490 the policy, and when it receives a negative response, must guess, 491 based upon what it has tried, what to do next. 493 2.10. Availability 495 Jamming attacks, cutting cables etc. leading to long term loss of 496 availability may not be possible to mitigate, but an attacker 497 temporarily injecting messages or disturbing the communication shall 498 not have a similar impact. 500 2.11. Lightweight 502 We target an AKE which is efficiently deployable in 6TiSCH multi-hop 503 networks, LoRaWAN networks and NB-IoT networks. (For an overview of 504 low-power wide area networks, see e.g. [RFC8376].) The desire is to 505 optimize the AKE to be 'as lightweight as reasonably achievable' in 506 these environments, where 'lightweight' refers to: 508 * resource consumption, measured by bytes on the wire, wall-clock 509 time and number of round trips to complete, or power consumption 511 * the amount of new code required on end systems which already have 512 an OSCORE stack 514 These properties need to be considered in the context of the use of 515 an existing CoAP/OSCORE stack in the targeted networks and 516 technologies. Some properties are difficult to evaluate for a given 517 protocol, for example, because they depend on the radio conditions or 518 other simultaneous network traffic. Additionally, these properties 519 are not independent. Therefore the properties listed here should be 520 taken as input for identifying plausible protocol metrics that can be 521 more easily measured and compared between protocols. 523 Per 'bytes on the wire', it is desirable for the AKE messages to fit 524 into the MTU size of these protocols; and if not possible, within as 525 few frames as possible, since using multiple MTUs can have 526 significant costs in terms of time and power. Note that the MTU size 527 depends on radio technology and its characteristics, including data 528 rates, number of hops, etc. Example benchmarks are given further 529 down in this section. 531 Per 'time', it is desirable for the AKE message exchange(s) to 532 complete in a reasonable amount of time, both for a single 533 uncongested exchange and when multiple exchanges are running in an 534 interleaved fashion, like e.g. in a "network formation" setting when 535 multiple devices connect for the first time. This latency may not be 536 a linear function depending on congestion and the specific radio 537 technology used. As these are relatively low data rate networks, the 538 latency contribution due to computation is in general not expected to 539 be dominant. 541 Per 'round-trips', it is desirable that the number of completed 542 request/response message exchanges required before the initiating 543 endpoint can start sending protected traffic data is as small as 544 possible, since this reduces completion time. See Section 2.11.4 for 545 a discussion about the trade-off between message size and number of 546 flights. 548 Per 'power', it is desirable for the transmission of AKE messages and 549 crypto to draw as little power as possible. The best mechanism for 550 doing so differs across radio technologies. For example, NB-IoT uses 551 licensed spectrum and thus can transmit at higher power to improve 552 coverage, making the transmitted byte count relatively more important 553 than for other radio technologies. In other cases, the radio 554 transmitter will be active for a full MTU frame regardless of how 555 much of the frame is occupied by message content, which makes the 556 byte count less sensitive for the power consumption as long as it 557 fits into the MTU frame. The power consumption thus increases with 558 AKE message size and the largest impact is on average under poor 559 network conditions. Note that listening for messages to receive can 560 in many cases be a large contribution to the power consumption, for 561 which there are separate techniques to handle, e.g., time slots, 562 discontinuous reception, etc. but this is not considered in scope of 563 the AKE design. 565 Per 'new code', it is desirable to introduce as little new code as 566 possible onto OSCORE-enabled devices to support this new AKE. These 567 devices have on the order of 10s of kB of memory and 100 kB of 568 storage on which an embedded OS; a COAP stack; CORE and AKE 569 libraries; and target applications would run. It is expected that 570 the majority of this space is available for actual application logic, 571 as opposed to the support libraries. In a typical OSCORE 572 implementation COSE encrypt and signature structures will be 573 available, as will support for COSE algorithms relevant for IoT 574 enabling the same algorithms as is used for OSCORE (e.g. COSE 575 algorithm no. 10 = CCM* used by 6TiSCH). The use of those, or CBOR 576 or CoAP, would not add to the footprint. 578 While the large variety of settings and capabilities of the devices 579 and networks makes it challenging to produce exact values of some 580 these dimensions, there are some key benchmarks that are tractable 581 for security protocol engineering and which have a significant 582 impact. 584 2.11.1. LoRaWAN 586 Reflecting deployment reality as of now, we focus on the European 587 regulation as described in ETSI EN 300 220. LoRaWAN employs 588 unlicensed radio frequency bands in the 868 MHz ISM band. For 589 LoRaWAN the most relevant metric is the Time-on-Air, which determines 590 the period before the next communication can occur and also which can 591 be used as an indicator to calculate energy consumption. LoRaWAN is 592 legally required to use a duty cycle with values such as 0.1%, 1% and 593 10% depending on the sub-band that is being used, leading to a 594 payload split into fragments interleaved with unavailable times. For 595 Europe, the duty cycle is 1% (or smaller). Although there are 596 exceptions from the use of duty cycle, the use of an AKE for 597 providing end-to-end security on application layer needs to comply 598 with the duty cycle. 600 2.11.1.1. Bytes on the wire 602 LoRaWAN has a variable MTU depending on the Spreading Factor (SF). 603 The higher the spreading factor, the higher distances can be achieved 604 and/or better reception. If the coverage and distance allows it, 605 with SF7 - corresponding to higher data rates - the maximum payload 606 is 222 bytes. For a SF12 - and low data rates - the maximum payload 607 is 51 bytes on data link layer. 609 The size and number of packets impact the Time-on-Air (ToA). The 610 benchmark used here is based on SF12 and a packet size of 51 bytes 611 [LoRaWAN]. The use of larger packets depend on good radio conditions 612 which are not always present. Some libraries/providers only support 613 51-bytes packet size. 615 2.11.1.2. Time 617 The time it takes to send a message over the air in LoRaWAN can be 618 calculated as a function of the different parameters of the 619 communication. These are the Spreading Factor (SF), the message 620 size, the channel, bandwidth, coding rate, etc. An important feature 621 of LoRaWAN is the duty cycle limitation due to the use of the ISM 622 band. The duty cycle is evaluated in a 1-hour sliding window. It is 623 legal for a device to transmit a burst for a total of up to 36 624 seconds ToA on a 1%-duty-cyle sub-band, but the device must then 625 pause the transmission for the rest of the hour [lorawan-duty-cycle]. 626 In order to avoid extreme waiting times, the AKE needs to complete 627 before the duty cycle limit is exhausted, also taking into account 628 potential retransmissions and allowing additional air time for lower 629 level MAC frames and application data. As a challenging but 630 realistic example we assume each message is retransmitted 2 times and 631 allow a factor 2-3 for additional air time. With these assumptions 632 it is required with a ToA of 4-6 seconds for the uplink protocol 633 messages to ensure that the entire burst stays within the 36 seconds 634 duty cycle. 636 It should be noted that some libraries/providers enforce the duty 637 cycle limitation through a stop-and-wait operation, which restricts 638 the number of bytes to the size of the packets after which duty cycle 639 waiting times are incurred. 641 2.11.1.3. Round trips and number of flights 643 Considering the duty cycle of LoRaWAN and associated unavailable 644 times, the round trips and number of LoRaWAN packets needs to be 645 reduced as much as possible. 647 2.11.1.4. Power 649 The calculation of the power consumption in LoRaWAN is dependent on 650 several factors, such as the spreading factor used and the length of 651 the messages sent, both having a clear dependency with the time it 652 takes to transmit the messages. The communication model (inherent to 653 the different LoRaWAN classes of devices) also has an impact on the 654 energy consumption, but overall the Time-on-Air is an important 655 indication of the performance. 657 2.11.2. 6TiSCH 659 6TiSCH operates in the 2.4 GHz unlicensed frequency band and uses 660 hybrid Time Division/Frequency Division multiple access (TDMA/FDMA). 661 Nodes in a 6TiSCH network form a mesh. The basic unit of 662 communication, a cell, is uniquely defined by its time and frequency 663 offset in the communication schedule matrix. Cells can be assigned 664 for communication to a pair of nodes in the mesh and so be collision- 665 free, or shared by multiple nodes, for example during network 666 formation. In case of shared cells, some collision-resolution scheme 667 such as slotted-Aloha is employed. Nodes exchange frames which are 668 at most 127-bytes long, including the link-layer headers. To 669 preserve energy, the schedule is typically computed in such a way 670 that nodes switch on their radio below 1% of the time ("radio duty 671 cycle"). A 6TiSCH mesh can be several hops deep. In typical use 672 cases considered by the 6TiSCH working group, a network that is 2-4 673 hops deep is commonplace; a network which is more than 8 hops deep is 674 not common. 676 2.11.2.1. Bytes on the wire 678 Increasing the number of bytes on the wire in a protocol message has 679 an important effect on the 6TiSCH network in case the fragmentation 680 is triggered. More fragments contribute to congestion of shared 681 cells (and concomitant error rates) in a non-linear way. 683 The available size for key exchange messages depends on the topology 684 of the network, whether the message is traveling uplink or downlink, 685 and other stack parameters. A key performance indicator for a 6TiSCH 686 network is "network formation", i.e. the time it takes from switching 687 on all devices, until the last device has executed the AKE and 688 securely joined. As a benchmark, given the size limit on the frames 689 and taking into account the different headers (including link-layer 690 security), for a 6TiSCH network 5 hops deep, the maximum CoAP payload 691 size to avoid fragmentation is 47/45 bytes (uplink/downlink) 692 [AKE-for-6TiSCH]. 694 2.11.2.2. Time 696 Given the slotted nature of 6TiSCH, the number of bytes in a frame 697 has insignificant impact on latency, but the number of frames has. 698 The relevant metric for studying AKE is the network formation time, 699 which implies parallel AKE runs among nodes that are attempting to 700 join the network. Network formation time directly affects the time 701 installers need to spend on site at deployment time. 703 2.11.2.3. Round trips and number of flights 705 Given the mesh nature of the 6TiSCH network, and given that each 706 message may travel several hops before reaching its destination, it 707 is highly desirable to minimize the number of round trips to reduce 708 latency. 710 2.11.2.4. Power 712 From the power consumption point of view, it is more favorable to 713 send a small number of large frames than a larger number of short 714 frames. 716 2.11.3. NB-IoT 718 3GPP has specified Narrow-Band IoT (NB-IoT) for support of infrequent 719 data transmission via user plane and via control plane. NB-IoT is 720 built on cellular licensed spectrum at low data rates for the purpose 721 of supporting: 723 * operations in extreme coverage conditions, 725 * device battery life of 10 years or more, 727 * low device complexity and cost, and 729 * a high system capacity of millions of connected devices per square 730 kilometer. 732 NB-IoT achieves these design objectives by: 734 * Reduced baseband processing, memory and RF enabling low complexity 735 device implementation. 737 * A lightweight setup minimizing control signaling overhead to 738 optimize power consumption. 740 * In-band, guard-band, and stand-alone deployment enabling efficient 741 use of spectrum and network infrastructure. 743 2.11.3.1. Bytes on the wire 745 The number of bytes on the wire in a protocol message has a direct 746 effect on the performance for NB-IoT. In contrast to LoRaWAN and 747 6TiSCH, the NB-IoT radio bearers are not characterized by a fixed 748 sized PDU. Concatenation, segmentation and reassembly are part of 749 the service provided by the NB-IoT radio layer. As a consequence, 750 the byte count has a measurable impact on time and energy consumption 751 for running the AKE. 753 2.11.3.2. Time 755 Coverage significantly impacts the available bit rate and thereby the 756 time for transmitting a message, and there is also a difference 757 between downlink and uplink transmissions (see Section 2.11.3.4). 758 The transmission time for a message is essentially proportional to 759 the number of bytes. 761 Since NB-IoT is operating in licensed spectrum, in contrast to e.g. 762 LoRaWAN, the packets on the radio interface can be transmitted back- 763 to-back, so the time before sending OSCORE protected data is limited 764 by the number of round trips/flights of the AKE and not by a duty 765 cycle. 767 2.11.3.3. Round trips and number of flights 769 As indicated in Section 2.11.3.2, the number of frames and round- 770 trips is one limiting factor for protocol completion time. 772 2.11.3.4. Power 774 Since NB-IoT is operating in licensed spectrum, the device is allowed 775 to transmit at a relatively high power, which has a large impact on 776 the energy consumption. 778 The benchmark for NB-IoT energy consumption is based on the same 779 computational model as was used by 3GPP in the design of this radio 780 layer [NB-IoT-battery-life-evaluation]. The device power consumption 781 is assumed to be 500mW for transmission and 80mW for reception. 782 Power consumption for "light sleep" (~ 3mW) and "deep sleep" (~ 783 0.015mW) are negligible in comparison. The bitrates (uplink/ 784 downlink) are assumed to be 28/170 kbps for good coverage and 785 0,37/2,5 kbps for bad coverage. 787 The results [AKE-for-NB-IoT] show a high per-byte energy consumption 788 for uplink transmissions, in particular in bad coverage. Given that 789 the application decides about the device being initiator or responder 790 in the AKE, the protocol cannot be tailored for a particular message 791 being uplink or downlink. To perform well in both kind of 792 applications the overall number of bytes of the protocol needs to be 793 as low as possible. 795 2.11.4. Discussion and Summary of Benchmarks 797 The difference between uplink and downlink performance must not be 798 engineered into the protocol since it cannot be assumed that a 799 particular protocol message will be sent uplink or downlink. 801 For NB-IoT the byte count on the wire has a measurable impact on time 802 and energy consumption for running the AKE, so the number of bytes in 803 the messages needs to be as low as possible. 805 While "as small protocol messages as possible" does not lend itself 806 to a sharp boundary threshold, "as few flights as possible" does and 807 is relevant in all settings above. 809 The penalty is high for not fitting into the frame sizes of 6TiSCH 810 and LoRaWAN networks. Fragmentation is not defined within these 811 technologies so requires fragmentation scheme on a higher layer in 812 the stack. With fragmentation increases the number of frames per 813 message, each with its associated overhead in terms of power 814 consumption and latency. Additionally the probability for errors 815 increases, which leads to retransmissions of frames or entire 816 messages that in turn increases the power consumption and latency. 818 There are trade-offs between "few messages" and "few frames"; if 819 overhead is spread out over more messages such that each message fits 820 into a particular frame this may reduce the overall power 821 consumption. For example, with a frame size of 50 bytes, two 60-byte 822 messages will fragment into 4 frames in total, whereas three 40-byte 823 messages fragment into 3 frames in total. On the other hand, a 824 smaller message has less probability to collide with other messages 825 and incur retransmission. 827 While it may be possible to engineer such a solution for a particular 828 radio technology and AKE protocol, optimizing for a specific scenario 829 may not be optimal for other settings. It is expected that specific 830 scenarios are evaluated in the design phase to ensure that the AKE is 831 fit for purpose. But in order to start the design work some general 832 criteria for the AKE performance need to be formulated that takes 833 into account the differences in the expected deployments. 835 There are benefits in terms of fewer flights/round trips for NB-IoT 836 (Section 2.11.3.3) and 6TiSCH (Section 2.11.2.3). An AKE protocol 837 complying with the requirements of this memo is expected to have at 838 least 3 messages. With a 3-message AKE, the initiator is able to 839 derive the OSCORE security context after receiving message 2, 840 rendering the AKE essentially one round trip before traffic data can 841 be exchanged, which is ideal. 843 If the AKE has 3 messages then optimal performance for 6TiSCH is when 844 each message fits into as few frames as possible, ideally 1 frame per 845 message. 847 For LoRaWAN, optimal performance is determined by the duty cycle 848 which puts a limit to ToA or, for certain libraries/providers, the 849 number of packets (see Section 2.11.1.2). If the AKE has 3 messages 850 and each message fits into a 51 byte packet then this is optimal for 851 the latter case. The same assumption incurs a ToA for uplink 852 messages in the interval of 4-6 seconds at SF12 both for a device- 853 initiated and infrastructure-initiated AKE, which complies with the 854 challenging example stated in Section 2.11.1.2. 856 One avenue to good performance is therefore to target message sizes 857 which avoids fragmentation or with as few fragments as possible. For 858 the LoRaWAN benchmark, the limit for fragmentation is 51 bytes at 859 link layer. For the 6TiSCH benchmark, messages less than or equal to 860 45 bytes at CoAP payload layer need not be fragmented. 862 For the initial focus cases (Section 2.2.1), i.e. RPK (by reference 863 and value) and certificate by reference, it is required that the AKE 864 shall perform optimally with respect to the available criteria for 865 the radio technologies. 867 To determine with certainty what are the minimal number of fragments 868 for an AKE under different assumptions requires to design and analyse 869 the AKE, which is clearly beyond the requirements phase. However, by 870 means of an example we have reason to believe that an AKE with 3 871 messages can be designed to support RPK by reference in 3 fragments. 872 Thus the ideal number of fragments is expected for RPK by reference. 874 While such performance may not be possible for the other initial 875 focus cases, it is expected that if one of the peers send RPK by 876 value or certificate by reference, then one additional fragment is 877 sufficient, thus in total a maximum of 5 fragments. Alternatively, 878 for the LoRaWAN challenge (Section 2.11.1.2), it is expected that the 879 duty cycle for a burst can be complied with for RPK by value and 880 certificate by reference, assuming that each message only needs to be 881 retransmitted at most once (i.e. good AKE performance for RPK by 882 value and certificate by reference in not too poor radio 883 environments). 885 2.11.5. AKE frequency 887 One question that has been asked in the context of lightweightness 888 is: - How often is the AKE executed? While it may be impossible to 889 give a precise answer there are other perspectives to this question. 891 1. For some use cases, already one execution of the AKE is heavy, 892 for example, because 894 * there are a number of parallel executions of the AKE which 895 loads down the network, such as in a network formation 896 setting, or 898 * the duty cycle makes the completion time long for even one run 899 of the protocol. 901 2. If a device reboots it may not be able to recover the security 902 context, e.g. due to lack of persistent storage, and is required 903 to establish a new security context for which an AKE is 904 preferred. Reboot frequency may be difficult to predict in 905 general. 907 3. To limit the impact of a key compromise, BSI, NIST and ANSSI and 908 other organizations recommend in other contexts frequent renewal 909 of keys by means of Diffie-Hellman key exchange. This may be a 910 symmetric key authenticated key exchange, where the symmetric key 911 is obtained from a previous asymmetric key based run of the AKE. 913 To summarize, even if it we are unable to give precise numbers for 914 AKE frequency, a lightweight AKE: 916 * reduces the time for network formation and AKE runs in challenging 917 radio technologies, 919 * allows devices to quickly re-establish security in case of 920 reboots, and 922 * enables support for recommendations of frequent key renewal. 924 3. Security Considerations 926 This document compiles the requirements for an AKE and provides some 927 related security considerations. 929 The AKE must provide the security properties expected of IETF 930 protocols, e.g., providing mutual authentication, confidentiality, 931 and negotiation integrity as is further detailed in the requirements. 933 4. Privacy Considerations 935 In the privacy properties for the AKE, the transport over CoAP needs 936 to be considered. 938 5. IANA Considerations 940 None. 942 Acknowledgments 944 The authors want to thank Richard Barnes, Dominique Barthel, Karthik 945 Bhargavan, Stephen Farrell, Ivaylo Petrov, Eric Rescorla, Michael 946 Richardson, Jesus Sanchez-Gomez, Claes Tidestav, Hannes Tschofenig 947 and Christopher Wood for providing valuable input. 949 Informative References 951 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 952 Constrained-Node Networks", RFC 7228, 953 DOI 10.17487/RFC7228, May 2014, 954 . 956 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 957 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 958 October 2013, . 960 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 961 Application Protocol (CoAP)", RFC 7252, 962 DOI 10.17487/RFC7252, June 2014, 963 . 965 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 966 the Constrained Application Protocol (CoAP)", RFC 7959, 967 DOI 10.17487/RFC7959, August 2016, 968 . 970 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 971 Bose, "Constrained Application Protocol (CoAP) Option for 972 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 973 August 2016, . 975 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 976 RFC 8152, DOI 10.17487/RFC8152, July 2017, 977 . 979 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 980 "Object Security for Constrained RESTful Environments 981 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 982 . 984 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 985 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 986 . 988 [I-D.ietf-6tisch-minimal-security] 989 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 990 "Constrained Join Protocol (CoJP) for 6TiSCH", Work in 991 Progress, Internet-Draft, draft-ietf-6tisch-minimal- 992 security-15, 10 December 2019, . 996 [I-D.ietf-lpwan-coap-static-context-hc] 997 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 998 Context Header Compression (SCHC) for CoAP", Work in 999 Progress, Internet-Draft, draft-ietf-lpwan-coap-static- 1000 context-hc-14, 26 May 2020, . 1003 [I-D.ietf-cose-x509] 1004 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1005 Header parameters for carrying and referencing X.509 1006 certificates", Work in Progress, Internet-Draft, draft- 1007 ietf-cose-x509-06, 9 March 2020, . 1010 [I-D.ietf-core-echo-request-tag] 1011 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 1012 Request-Tag, and Token Processing", Work in Progress, 1013 Internet-Draft, draft-ietf-core-echo-request-tag-09, 9 1014 March 2020, . 1017 [I-D.irtf-cfrg-randomness-improvements] 1018 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 1019 and C. Wood, "Randomness Improvements for Security 1020 Protocols", Work in Progress, Internet-Draft, draft-irtf- 1021 cfrg-randomness-improvements-12, 5 May 2020, 1022 . 1025 [I-D.selander-ace-ake-authz] 1026 Selander, G., Mattsson, J., Vucinic, M., Richardson, M., 1027 and A. Schellenbaum, "Lightweight Authorization for 1028 Authenticated Key Exchange.", Work in Progress, Internet- 1029 Draft, draft-selander-ace-ake-authz-01, 9 March 2020, 1030 . 1033 [AKE-for-6TiSCH] 1034 "AKE for 6TiSCH", March 2019, 1035 . 1038 [AKE-for-NB-IoT] 1039 "AKE for NB-IoT", March 2019, 1040 . 1043 [NB-IoT-battery-life-evaluation] 1044 "On mMTC, NB-IoT and eMTC battery life evaluation", 1045 January 2017, 1046 . 1049 [HKDF] Krawczyk, H., "Cryptographic Extraction and Key 1050 Derivation: The HKDF Scheme", May 2010, 1051 . 1053 [IANA-COSE-Algorithms] 1054 "COSE Algorithms", March 2020, 1055 . 1058 [LwM2M] "OMA SpecWorks LwM2M", August 2018, 1059 . 1063 [OCF] "OSCORE:OCF Status and Comments", March 2020, 1064 . 1068 [LoRaWAN] "LoRaWAN Regional Parameters v1.0.2rB", February 2017, 1069 . 1072 [LAKE-WG] "LAKE WG", March 2020, 1073 . 1075 [KCI] Hlauschek, C., Gruber, M., Fankhauser, F., and C. Schanes, 1076 "Prying open Pandoras box:KCI attacks against TLS", August 1077 2015, 1078 . 1081 [Misbinding] 1082 Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 1083 on Secure Device Pairing and Bootstrapping", Proceedings 1084 of the 2019 ACM Asia Conference on Computer and 1085 Communications Security , May 2019, 1086 . 1088 [Selfie] Drucker, N. and S. Gueron, "Selfie:Reflections on TLS 1.3 1089 with PSK", March 2019, . 1091 [massive-breach] 1092 "Sim card database hack gave US and UK spies access to 1093 billions of cellphones", February 2015, 1094 . 1097 [lorawan-duty-cycle] 1098 Saelens, M., Hoebeke, J., Shahid, A., and E. De Poorter, 1099 "Impact of EU duty cycle and transmission power 1100 limitations for sub-GHz LPWAN SRDs an overview and future 1101 challenges. EURASIP Journal on Wireless Communications and 1102 Networking. 2019. 10.1186/s13638-019-1502-5.", 2019, 1103 . 1107 [keylength] 1108 Lenstra, A., "Key Lengths:Contribution to The Handbook of 1109 Information Security", 2018, 1110 . 1113 Authors' Addresses 1115 Malisa Vucinic 1116 Inria 1118 Email: malisa.vucinic@inria.fr 1120 Goeran Selander 1121 Ericsson AB 1123 Email: goran.selander@ericsson.com 1125 John Preuss Mattsson 1126 Ericsson AB 1128 Email: john.mattsson@ericsson.com 1130 Dan Garcia-Carrillo 1131 Odin Solutions S.L. 1133 Email: dgarcia@odins.es