idnits 2.17.1 draft-ietf-lake-reqs-01.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 (19 February 2020) is 1526 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-lpwan-coap-static-context-hc-12 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-05 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-08 == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-randomness-improvements-09 == Outdated reference: A later version (-05) exists of draft-selander-ace-ake-authz-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). 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: 22 August 2020 J. Mattsson 6 Ericsson AB 7 D. Garcia 8 Odin Solutions S.L. 9 19 February 2020 11 Requirements for a Lightweight AKE for OSCORE 12 draft-ietf-lake-reqs-01 14 Abstract 16 This document compiles the requirements for a lightweight 17 authenticated key exchange protocol for OSCORE. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 22 August 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. AKE for OSCORE . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 6 57 2.4. Confidentiality . . . . . . . . . . . . . . . . . . . . . 7 58 2.5. Cryptographic Agility and Negotiation Integrity . . . . . 7 59 2.6. Identity Protection . . . . . . . . . . . . . . . . . . . 8 60 2.7. Auxiliary Data . . . . . . . . . . . . . . . . . . . . . 9 61 2.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 62 2.9. Denial of Service . . . . . . . . . . . . . . . . . . . . 10 63 2.10. Lightweight . . . . . . . . . . . . . . . . . . . . . . . 10 64 2.10.1. LoRaWAN . . . . . . . . . . . . . . . . . . . . . . 12 65 2.10.2. 6TiSCH . . . . . . . . . . . . . . . . . . . . . . . 13 66 2.10.3. NB-IoT . . . . . . . . . . . . . . . . . . . . . . . 14 67 2.10.4. Discussion . . . . . . . . . . . . . . . . . . . . . 16 68 2.10.5. AKE frequency . . . . . . . . . . . . . . . . . . . 17 69 3. Requirements Summary . . . . . . . . . . . . . . . . . . . . 17 70 4. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Informative References . . . . . . . . . . . . . . . . . . . . . 18 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 76 1. Introduction 78 OSCORE [RFC8613] is a lightweight communication security protocol 79 providing end-to-end security on application layer for constrained 80 IoT settings (cf. [RFC7228]). OSCORE lacks a matching authenticated 81 key exchange protocol (AKE). The intention with LAKE is to create a 82 simple yet secure AKE for implementation in embedded devices 83 supporting OSCORE. 85 To ensure that the AKE is efficient for the expected applications of 86 OSCORE, we list the relevant public specifications of technologies 87 where OSCORE is included: 89 * The IETF 6TiSCH WG charter (-02) identifies the need to "secur[e] 90 the join process and mak[e] that fit within the constraints of 91 high latency, low throughput and small frame sizes that 92 characterize IEEE802.15.4 TSCH". OSCORE protects the join 93 protocol as described in 6TiSCH Minimal Security 94 [I-D.ietf-6tisch-minimal-security]. 96 * The IETF LPWAN WG charter (-01) identifies the need to improve the 97 transport capabilities of LPWA networks such as NB-IoT and LoRa 98 whose "common traits include ... frame sizes ... [on] the order of 99 tens of bytes transmitted a few times per day at ultra-low 100 speeds". The application of OSCORE is described in 101 [I-D.ietf-lpwan-coap-static-context-hc]. 103 * OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two 104 challenging radio technologies where OSCORE will be deployed: 105 LoRaWAN and NB-IoT. 107 Other industry fora which plan to use OSCORE: 109 * Open Connectivity Foundation (OCF) has been actively involved in 110 the OSCORE development for the purpose of deploying OSCORE. 112 * Fairhair Alliance has defined an architecture [Fairhair] which 113 adopts OSCORE for multicast, but it is not clear whether the 114 architecture will support unicast OSCORE. Fairhair Alliance 115 merged with OCF in November 2019. 117 This document compiles the requirements for the AKE for OSCORE. It 118 summarizes the security requirements that are expected from such an 119 AKE, as well as the main characteristics of the environments where 120 the solution is envisioned to be deployed. The solution will 121 presumably be useful in other scenarios as well since a low security 122 overhead improves the overall performance. 124 2. Problem description 126 2.1. AKE for OSCORE 128 The rationale for designing this protocol is that OSCORE is lacking a 129 matching AKE. OSCORE was designed for lightweight RESTful operations 130 for example by minimizing the overhead, and applying the protection 131 to the application layer, thereby limiting the data being encrypted 132 and integrity protected for the other endpoint. Moreover, OSCORE was 133 tailored for use with lightweight primitives that are likely to be 134 implemented in the device, specifically CoAP, CBOR and COSE. The 135 same properties must apply to 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 146 * COSE algorithms to use with OSCORE 148 COSE provides the crypto primitives for OSCORE, and shall therefore 149 be used also by the AKE, for several reasons including maintenance of 150 crypto library. COSE provides identification of credentials and 151 algorithms for OSCORE and the AKE, and an extension point for new 152 schemes. 154 The AKE cannot rely on messages being exchanged in both directions 155 after the AKE has completed, because CoAP/OSCORE requests may not 156 have a response [RFC7967]. Furthermore, there is no assumption of 157 dependence between CoAP client/server and AKE initiator/responder 158 roles, and an OSCORE context may be used with CoAP client and server 159 roles interchanged as is done, for example, in [LwM2M]. 161 Moreover, the AKE must support transport over CoAP. Since the AKE 162 messages most commonly will be encapsulated in CoAP, the AKE must not 163 duplicate functionality provided by CoAP, or at least not duplicate 164 functionality in such a way that it adds extra costs in terms of code 165 size, code maintenance, etc. It is therefore assumed that the AKE is 166 being transported in a protocol that provides reliable transport, 167 that can preserve packet ordering and handle message duplication, 168 that can perform fragmentation and protect against denial of service 169 attacks, such as provided by the CoAP Echo option 170 [I-D.ietf-core-echo-request-tag]. 172 The AKE may use other transport than CoAP. In this case the 173 underlying layers must correspondingly handle message loss, 174 reordering, message duplication, fragmentation, and denial of service 175 protection. 177 2.2. Credentials 179 IoT deployments differ in terms of what credentials can be supported. 180 Currently many systems use pre-shared keys (PSKs) provisioned out of 181 band, for various reasons. PSKs are often used in a first deployment 182 because of their perceived simplicity. The use of PSKs allows for 183 protection of communication without major additional security 184 processing, and also enables the use of symmetric crypto algorithms 185 only, reducing the implementation and computational effort in the 186 endpoints. 188 However, PSK-based provisioning has inherent weaknesses. There has 189 been reports of massive breaches of PSK provisioning systems, and as 190 many systems use PSKs without perfect forward secrecy (PFS) they are 191 vulnerable to passive pervasive monitoring. The security of these 192 systems can be improved by adding PFS through an AKE authenticated by 193 the provisioned PSK. 195 Shared keys can alternatively be established in the endpoints using 196 an AKE protocol authenticated with asymmetric public keys instead of 197 symmetric secret keys. Raw public keys (RPK) can be provisioned with 198 the same scheme as PSKs, which allows for a more relaxed trust model 199 since RPKs need not be secret. The corresponding private keys are 200 assumed to be provisioned to the party being authenticated beforehand 201 (e.g. in factory or generated on-board). 203 As a third option, by using a public key infrastructure and running 204 an asymmetric key AKE with public key certificates instead of RPKs, 205 key provisioning can be omitted, leading to a more automated ("zero- 206 touch") bootstrapping procedure. The root CA keys are assumed to be 207 provisioned beforehand. 209 These steps provide an example of a migration path in limited scoped 210 steps from simple to more robust security bootstrapping and 211 provisioning schemes where each step improves the overall security 212 and/or simplicity of deployment of the IoT system, although not all 213 steps are necessarily feasible for the most constrained settings. 215 In order to allow for these different schemes, the AKE must support 216 PSK- (shared between two nodes), RPK- and certificate-based 217 authentication. 219 Multiple public key authentication credential types may need to be 220 supported for RPK and certificate-based authentication. In case of a 221 Diffie-Hellman key exchange both the use of signature based public 222 keys (for compatibility with existing ecosystem) and static DH public 223 keys (for reduced message size) is expected. 225 To further minimize the bandwidth consumption it is required to 226 support transporting the certificates by reference rather than by 227 value. Considering the wide variety of deployments the AKE must 228 support different schemes for transporting and identifying 229 credentials, including those identified in Section 2 of 230 [I-D.ietf-cose-x509]. 232 The common lack of a user interface in constrained devices leads to 233 various credential provisioning schemes. The use of RPKs may be 234 appropriate for the authentication of the AKE initiator but not for 235 the AKE responder. The AKE must support different credentials for 236 authentication in different directions of the AKE run, e.g. 237 certificate-based authentication for the initiating endpoint and RPK- 238 based authentication for the responding endpoint. 240 Assuming that both signature public keys and static DH public keys 241 are in use, then also the case of mixed credentials need to be 242 supported with one endpoint using a static DH public key and the 243 other using a signature public key. The AKE shall support the 244 initiator signaling which public key credential mix to be used in the 245 protocol such that the responder knows and can verify that the 246 intended variant was executed. 248 2.3. Mutual Authentication 250 The AKE must provide mutual authentication during the protocol run. 251 At the end of the AKE protocol, each endpoint shall have 252 authenticated the other's credential. In particular, both endpoints 253 must agree on a fresh session identifier, and the roles and 254 credentials of both endpoints. 256 Since the protocol may be initiated by different endpoints, it shall 257 not be necessary to determine beforehand which endpoint takes the 258 role of initiator of the AKE. 260 The mutual authentication guarantees of the AKE shall at least 261 guarantee the following properties: 263 * The AKE shall provide Key Compromise Impersonation (KCI) 264 resistance. 266 * The AKE shall protect against identity misbinding attacks, when 267 applicable. Note that the identity may be directly related to a 268 public key such as for example the public key itself, a hash of 269 the public key, or data unrelated to a key. 271 * The AKE shall protect against reflection attacks, but need not 272 protect against attacks when more than two parties legitimately 273 share keys (cf. the Selfie attack on TLS 1.3) as that setting is 274 out of scope. 276 Moreover, it shall be possible for the receiving endpoint to detect a 277 replayed AKE message. 279 Furthermore, the endpoints shall be able to verify that the identity 280 of the other endpoint is an acceptable identity that it is intended 281 to authenticate to. (This requirement extends beyond the AKE in that 282 the application must enable access to information about acceptable 283 identities without compromising the overall lightweightness of the 284 AKE.) 286 As often is the case, it is expected that an AKE fulfilling these 287 goals would have at least three flights of messages (with each flight 288 potentially consisting of one or more messages, depending on the AKE 289 design and the mapping to OSCORE). 291 2.4. Confidentiality 293 The shared secret established by the AKE must be known only to the 294 two authenticated endpoints. 296 A passive network attacker should never learn any session keys, even 297 if it knows both endpoints' long-term keys. 299 An active attacker who has compromised the initiator or responder 300 credential shall still not be able to compute past session keys 301 (Perfect Forward Secrecy). These properties can be achieved e.g. 302 with an ephemeral Diffie-Hellman key exchange. 304 Perfect Forward Secrecy may alternatively be achieved with a nonce 305 exchange followed by appropriately derived new session keys provided 306 that state can be kept in the form of a session counter. Note that 307 OSCORE specifies a method for session key update involving a nonce 308 exchange (see Appendix B in [RFC8613]). 310 The AKE shall provide a mechanism to use the output of one handshake 311 to optimize future handshakes, e.g., by generating keying material 312 which can be used to authenticate a future handshake, thus avoiding 313 the need for public key authentication in that handshake. 315 To mitigate against bad random number generators the AKE shall 316 mandate randomness improvements such as 317 [I-D.irtf-cfrg-randomness-improvements]. 319 2.5. Cryptographic Agility and Negotiation Integrity 321 Motivated by long deployment lifetimes, the AKE is required to 322 support cryptographic agility, including the modularity of COSE 323 crypto algorithms and negotiation of preferred crypto algorithms for 324 OSCORE and the AKE. 326 * The protocol shall support both pre-shared key and asymmetric key 327 authentication. PAKE and post-quantum key exchange is out of 328 scope, but may be supported in a later version. 330 * The protocol shall allow multiple elliptic curves for Diffie- 331 Hellman operations and signature-based authentication. 333 * The AKE shall support negotiation of all the COSE algorithms to be 334 used in the AKE and in OSCORE. A successful negotiation shall 335 result in the most preferred algorithms of one of the parties 336 which are supported by the other. 338 * The AKE may choose different sets of symmetric crypto algorithms 339 (AEAD, MAC, etc.) for AKE and for OSCORE. In particular, the 340 length of the MAC for the AKE may be required to be larger than 341 for OSCORE. 343 The AKE negotiation must provide strong integrity guarantees against 344 active attackers. At the end of the AKE protocol, both endpoints 345 must agree on both the crypto algorithms that were proposed and those 346 that were chosen. In particular, the protocol must protect against 347 downgrade attacks. 349 2.6. Identity Protection 351 In general, it is necessary to transport identities as part of the 352 AKE run in order to provide authentication of an entity not 353 identified beforehand. In the case of constrained devices, the 354 identity may contain sensitive information on the manufacturer of the 355 device, the batch, default firmware version, etc. Protecting 356 identifying information from passive and active attacks is important 357 from a privacy point of view, but needs to be balanced with the other 358 requirements, including security and lightweightness. For certain 359 data we therefore need to make an exemption in order to obtain an 360 efficient protocol. 362 In the case of public key identities, the AKE is required to protect 363 the identity of one of the peers against active attackers and the 364 identity of the other peer against passive attackers. 366 In case of a PSK identifier, this may be protected against passive 367 attackers, for example with a key derived from a Diffie-Hellman 368 shared secret at the earliest in flight 3. As a consequence, in 369 order to authenticate the responder within the AKE, at least four 370 protocol flights are needed in case of symmetric key authentication 371 with identity protection. Considering the need to keep the number of 372 round-trips at a minimum (see Section 2.10.4), unless there are other 373 good reasons for having more than 3 flights, it is not required to 374 protect the PSK identifier, and it may thus be sent in the first 375 flight. 377 Other identifying information that needs to be transported in plain 378 text is cipher suites and connection identifiers. Encrypting crypto 379 algorithms does not allow negotiation of cipher suite within 3 380 flights. Encryption of connection identifiers only works in 381 asymmetric case and does not enable arbitrarily short identifiers 382 (see Section 2.1). 384 2.7. Auxiliary Data 386 In order to reduce round trips and the number of flights, and in some 387 cases also streamline processing, certain security features may be 388 integrated into the AKE by transporting auxiliary data together with 389 the AKE messages. 391 One example is the transport of third-party authorization information 392 such as an access token or a voucher from initiator to responder or 393 vice versa. Such a scheme could enable the party receiving the 394 authorization information to make a decision about whether the party 395 being authenticated is also authorized before the protocol is 396 completed, and if not then discontinue the protocol before it is 397 complete, thereby saving time, message processing and data 398 transmission. This application can be further optimized by using an 399 AKE with static DH keys [I-D.selander-ace-ake-authz]. 401 Another example is the embedding of a certificate enrolment request 402 or a newly issued certificate. 404 The AKE must support the transport of such auxiliary data together 405 with the protocol messages. 407 Auxiliary data may contain privacy sensitive information. The 408 auxiliary data must not violate the AKE security properties. The AKE 409 needs to provide clear guidance on the level of security provided to 410 auxiliary data at different stages of the protocol. 412 For example, for a SIGMA-I AKE it is expected that the 3 flights will 413 provide the following protection of the auxiliary data: 415 * Auxiliary data in the first flight is unprotected 417 * Auxiliary data in the second flight is confidentiality protected 418 against passive attackers and integrity protected against active 419 attackers 421 * Auxiliary data in the third flight is confidentiality and 422 integrity protected against active attackers 424 2.8. Extensibility 426 It is desirable that the AKE supports some kind of extensibility, in 427 particular, the ability to later include new AKE modes such as PAKE 428 support. Note that by supporting COSE, the AKE can already support 429 new algorithms, new certificate formats, ways to identify 430 credentials, etc. 432 The main objective with this work is to create a simple yet secure 433 AKE. The AKE should avoid having multiple ways to express the same 434 thing. When the underlying encodings offered by CBOR offer multiple 435 possibility the AKE should be strongly opinioniated, and clearly 436 specify which one will be used. 438 While remaining extensible, the AKE should avoid optional mechanisms 439 which introduce code paths that are less well tested. 441 The AKE should avoid mechanisms where an initiator takes a guess at 442 the policy, and when it receives a negative response, must guess, 443 based upon what it has tried, what to do next. 445 2.9. Denial of Service 447 The AKE shall protect against denial of service attacks on responder 448 and initiator to the extent that the protocol supports lightweight 449 deployments (see Section 2.10) and without duplicating the DoS 450 mitigation of the underlying transport (see Section 2.1). 452 Jamming attacks, cutting cables etc. leading to long term loss of 453 availability may not be possible to mitigate, but an attacker 454 temporarily injecting messages or disturbing the communication shall 455 not have a similar impact. 457 2.10. Lightweight 459 We target an AKE which is efficiently deployable in 6TiSCH multi-hop 460 networks, LoRaWAN networks and NB-IoT networks. The desire is to 461 optimize the AKE to be 'as lightweight as reasonably achievable' in 462 these environments, where 'lightweight' refers to: 464 * resource consumption, measured by bytes on the wire, wall-clock 465 time and number of round trips to complete, or power consumption 467 * the amount of new code required on end systems which already have 468 an OSCORE stack 470 These properties need to be considered in the context of the use of 471 an existing CoAP/OSCORE stack in the targeted networks and 472 technologies. Some properties are difficult to evaluate for a given 473 protocol, for example, because they depend on the radio conditions or 474 other simultaneous network traffic. Additionally, these properties 475 are not independent. Therefore the properties listed here should be 476 taken as input for identifying plausible protocol metrics that can be 477 more easily measured and compared between protocols. 479 Per 'bytes on the wire', it is desirable for the AKE messages to fit 480 into the MTU size of these protocols; and if not possible, within as 481 few frames as possible, since using multiple MTUs can have 482 significant costs in terms of time and power. Note that the MTU size 483 depends on radio technology and its characteristics, including data 484 rates, number of hops, etc. Example benchmarks are given further 485 down in this section. 487 Per 'time', it is desirable for the AKE message exchange(s) to 488 complete in a reasonable amount of time, both for a single 489 uncongested exchange and when multiple exchanges are running in an 490 interleaved fashion, like e.g. in a "network formation" setting when 491 multiple devices connect for the first time. This latency may not be 492 a linear function depending on congestion and the specific radio 493 technology used. As these are relatively low data rate networks, the 494 latency contribution due to computation is in general not expected to 495 be dominant. 497 Per 'round-trips', it is desirable that the number of completed 498 request/response message exchanges required before the initiating 499 endpoint can start sending protected traffic data is as small as 500 possible, since this reduces completion time. See Section 2.10.4 for 501 a discussion about the tradeoff between message size and number of 502 flights. 504 Per 'power', it is desirable for the transmission of AKE messages and 505 crypto to draw as little power as possible. The best mechanism for 506 doing so differs across radio technologies. For example, NB-IoT uses 507 licensed spectrum and thus can transmit at higher power to improve 508 coverage, making the transmitted byte count relatively more important 509 than for other radio technologies. In other cases, the radio 510 transmitter will be active for a full MTU frame regardless of how 511 much of the frame is occupied by message content, which makes the 512 byte count less sensitive for the power consumption as long as it 513 fits into the MTU frame. The power consumption thus increases with 514 AKE message size and the largest impact is on average under poor 515 network conditions. 517 Per 'new code', it is desirable to introduce as little new code as 518 possible onto OSCORE-enabled devices to support this new AKE. These 519 devices have on the order of 10s of kB of memory and 100 kB of 520 storage on which an embedded OS; a COAP stack; CORE and AKE 521 libraries; and target applications would run. It is expected that 522 the majority of this space is available for actual application logic, 523 as opposed to the support libraries. In a typical OSCORE 524 implementation COSE encrypt and signature structures will be 525 available, as will support for COSE algorithms relevant for IoT 526 enabling the same algorithms as is used for OSCORE (e.g. COSE 527 algorithm no. 10 = CCM* used by 6TiSCH). The use of those, or CBOR 528 or CoAP, would not add to the footprint. 530 While the large variety of settings and capabilities of the devices 531 and networks makes it challenging to produce exact values of some 532 these dimensions, there are some key benchmarks that are tractable 533 for security protocol engineering and which have a significant 534 impact. 536 2.10.1. LoRaWAN 538 Reflecting deployment reality as of now, we focus on the European 539 regulation as described in ETSI EN 300 220. LoRaWAN employs 540 unlicensed radio frequency bands in the 868 MHz ISM band. For 541 LoRaWAN the most relevant metric is the Time-on-Air, which determines 542 the period before the next communication can occur and also which can 543 be used as an indicator to calculate energy consumption. LoRaWAN is 544 legally required to use a duty cycle with values such as 0.1%, 1% and 545 10% depending on the sub-band that is being used, leading to a 546 payload split into fragments interleaved with unavailable times. For 547 Europe, the duty cycle is 1% (or smaller). Although there are 548 exceptions from the use of duty cycle, the use of an AKE for 549 providing end-to-end security on application layer needs to comply 550 with the duty cycle. 552 2.10.1.1. Bytes on the wire 554 LoRaWAN has a variable MTU depending on the Spreading Factor (SF). 555 The higher the spreading factor, the higher distances can be achieved 556 and/or better reception. If the coverage and distance allows it, 557 with SF7 - corresponding to higher data rates - the maximum payload 558 is 222 bytes. For a SF12 - and low data rates - the maximum payload 559 is 51 bytes. 561 The benchmark used here is Data Rates 0-2 corresponding to a packet 562 size of 51 bytes [LoRaWAN]. The use of larger frame size depend on 563 good radio conditions which are not always present. Some libraries/ 564 providers only support 51-bytes packet size. 566 2.10.1.2. Time 568 The time it takes to send a message over the air in LoRaWAN can be 569 calculated as a function of the different parameters of the 570 communication. These are the Spreading Factor (SF), the message 571 size, the channel, bandwidth, coding rate, etc. An important feature 572 of LoRaWAN is the duty cycle limitation due to the use of the ISM 573 band. A duty cycle of 1% implies that the time to complete a 574 fragmentation of the payload increases by at least 10,000%. This 575 limitation determines how long time the device will have to wait for 576 next use, which encourages the reduction of the message size as much 577 as possible. 579 2.10.1.3. Round trips and number of flights 581 Considering the duty cycle of LoRaWAN and associated unavailable 582 times, the round trips and number of LoRaWAN packets needs to be 583 reduced as much as possible. 585 2.10.1.4. Power 587 The calculation of the power consumption in LoRaWAN is dependent on 588 several factors, such as the spreading factor used and the length of 589 the messages sent, both having a clear dependency with the time it 590 takes to transmit the messages. The communication model (inherent to 591 the different LoRaWAN classes of devices) also has an impact on the 592 energy consumption, but overall the Time-on-Air is an important 593 indication of the performance. 595 2.10.2. 6TiSCH 597 6TiSCH operates in the 2.4 GHz unlicensed frequency band and uses 598 hybrid Time Division/Frequency Division multiple access (TDMA/FDMA). 599 Nodes in a 6TiSCH network form a mesh. The basic unit of 600 communication, a cell, is uniquely defined by its time and frequency 601 offset in the communication schedule matrix. Cells can be assigned 602 for communication to a pair of nodes in the mesh and so be collision- 603 free, or shared by multiple nodes, for example during network 604 formation. In case of shared cells, some collision-resolution scheme 605 such as slotted-Aloha is employed. Nodes exchange frames which are 606 at most 127-bytes long, including the link-layer headers. To 607 preserve energy, the schedule is typically computed in such a way 608 that nodes switch on their radio below 1% of the time ("radio duty 609 cycle"). A 6TiSCH mesh can be several hops deep. In typical use 610 cases considered by the 6TiSCH working group, a network that is 2-4 611 hops deep is commonplace; a network which is more than 8 hops deep is 612 not common. 614 2.10.2.1. Bytes on the wire 616 Increasing the number of bytes on the wire in a protocol message has 617 an important effect on the 6TiSCH network in case the fragmentation 618 is triggered. More fragments contribute to congestion of shared 619 cells (and concomitant error rates) in a non-linear way. 621 The available size for key exchange messages depends on the topology 622 of the network, whether the message is traveling uplink or downlink, 623 and other stack parameters. A key performance indicator for a 6TiSCH 624 network is "network formation", i.e. the time it takes from switching 625 on all devices, until the last device has executed the AKE and 626 securely joined. As an example, given the size limit on the frames 627 and taking into account the different headers (including link-layer 628 security), if a 6TiSCH network is 5 hops deep, the maximum CoAP 629 payload size to avoid fragmentation is 47/45 bytes (uplink/downlink) 630 [AKE-for-6TiSCH]. 632 2.10.2.2. Time 634 Given the slotted nature of 6TiSCH, the number of bytes in a frame 635 has insignificant impact on latency, but the number of frames has. 636 The relevant metric for studying AKE is the network formation time, 637 which implies parallel AKE runs among nodes that are attempting to 638 join the network. Network formation time directly affects the time 639 installers need to spend on site at deployment time. 641 2.10.2.3. Round trips and number of flights 643 Given the mesh nature of the 6TiSCH network, and given that each 644 message may travel several hops before reaching its destination, it 645 is highly desirable to minimize the number of round trips to reduce 646 latency. 648 2.10.2.4. Power 650 From the power consumption point of view, it is more favorable to 651 send a small number of large frames than a larger number of short 652 frames. 654 2.10.3. NB-IoT 656 3GPP has specified Narrow-Band IoT (NB-IoT) for support of infrequent 657 data transmission via user plane and via control plane. NB-IoT is 658 built on cellular licensed spectrum at low data rates for the purpose 659 of supporting: 661 * operations in extreme coverage conditions, 663 * device battery life of 10 years or more, 665 * low device complexity and cost, and 667 * a high system capacity of millions of connected devices per square 668 kilometer. 670 NB-IoT achieves these design objectives by: 672 * Reduced baseband processing, memory and RF enabling low complexity 673 device implementation. 675 * A lightweight setup minimizing control signaling overhead to 676 optimize power consumption. 678 * In-band, guard-band, and stand-alone deployment enabling efficient 679 use of spectrum and network infrastructure. 681 2.10.3.1. Bytes on the wire 683 The number of bytes on the wire in a protocol message has a direct 684 effect on the performance for NB-IoT. In contrast to LoRaWAN and 685 6TiSCH, the NB-IoT radio bearers are not characterized by a fixed 686 sized PDU. Concatenation, segmentation and reassembly are part of 687 the service provided by the NB-IoT radio layer. As a consequence, 688 the byte count has a measurable impact on time and energy consumption 689 for running the AKE. 691 2.10.3.2. Time 693 Coverage significantly impacts the available bit rate and thereby the 694 time for transmitting a message, and there is also a difference 695 between downlink and uplink transmissions (see Section 2.10.3.4). 696 The transmission time for a message is essentially proportional to 697 the number of bytes. 699 Since NB-IoT is operating in licensed spectrum, in contrast to e.g. 700 LoRaWAN, the packets on the radio interface can be transmitted back- 701 to-back, so the time before sending OSCORE protected data is limited 702 by the number of round trips/flights of the AKE and not by a duty 703 cycle. 705 2.10.3.3. Round trips and number of flights 707 As indicated in Section 2.10.3.2, the number of frames and round- 708 trips is one limiting factor for protocol completion time. 710 2.10.3.4. Power 712 Since NB-IoT is operating in licensed spectrum, the device is allowed 713 to transmit at a relatively high power, which has a large impact on 714 the energy consumption. 716 The benchmark for NB-IoT energy consumption is based on the same 717 computational model as was used by 3GPP in the design of this radio 718 layer [NB-IoT-battery-life-evaluation]. The device power consumption 719 is assumed to be 500mW for transmission and 80mW for reception. 721 Power consumption for "light sleep" (~ 3mW) and "deep sleep" (~ 722 0.015mW) are negligible in comparison. The bitrates (uplink/ 723 downlink) are assumed to be 28/170 kbps for good coverage and 724 0,37/2,5 kbps for bad coverage. 726 The results [AKE-for-NB-IoT] show a high per-byte energy consumption 727 for uplink transmissions, in particular in bad coverage. Given that 728 the application decides about the device being initiator or responder 729 in the AKE, the protocol cannot be tailored for a particular message 730 being uplink or downlink. To perform well in both kind of 731 applications the overall number of bytes of the protocol needs to be 732 as low as possible. 734 2.10.4. Discussion 736 While "as small protocol messages as possible" does not lend itself 737 to a sharp boundary threshold, "as few flights as possible" does and 738 is relevant in all settings above. 740 The penalty is high for not fitting into the frame sizes of 6TiSCH 741 and LoRaWAN networks. Fragmentation is not defined within these 742 technologies so requires fragmentation scheme on a higher layer in 743 the stack. With fragmentation increases the number of frames per 744 message, each with its associated overhead in terms of power 745 consumption and latency. Additionally the probability for errors 746 increases, which leads to retransmissions of frames or entire 747 messages that in turn increases the power consumption and latency. 749 There are trade-offs between "few messages" and "few frames"; if 750 overhead is spread out over more messages such that each message fits 751 into a particular frame this may reduce the overall power 752 consumption. For example, with a frame size of 50 bytes, two 60-byte 753 messages will fragment into 4 frames in total, whereas three 40-byte 754 messages fragment into 3 frames in total. While it may be possible 755 to engineer such a solution for a particular radio technology and 756 signature algorithm, the benefits in terms of fewer flights/round 757 trips in general and for NB-IoT in particular (see Section 2.10.3) 758 are considered more important than optimizing for a specific 759 scenario. Considering that an AKE protocol complying with these 760 requirements is expected to have at least 3 messages, the optimal AKE 761 has 3 messages and each message fits into as few frames as possible, 762 ideally 1 frame per message. 764 The difference between uplink and downlink performance should not be 765 engineered into the protocol since it cannot be assumed that a 766 particular protocol message will be sent uplink or downlink. 768 2.10.5. AKE frequency 770 One question that has been asked in the context of lightweightness 771 is: - How often is the AKE executed? While it may be impossible to 772 give a precise answer there are other perspectives to this question. 774 1. For some use cases, already one execution of the AKE is heavy, 775 for example, because 777 * there are a number of parallel executions of the AKE which 778 loads down the network, such as in a network formation 779 setting, or 781 * the duty cycle makes the completion time long for even one run 782 of the protocol. 784 2. If a device reboots it may not be able to recover the security 785 context, e.g. due to lack of persistent storage, and is required 786 to establish a new security context for which an AKE is 787 preferred. Reboot frequency may be difficult to predict in 788 general. 790 3. To limit the impact of a key compromise, BSI, NIST and ANSSI and 791 other organizations recommend in other contexts frequent renewal 792 of keys by means of Diffie-Hellman key exchange. This may be a 793 symmetric key authenticated key exchange, where the symmetric key 794 is obtained from a previous asymmetric key based run of the AKE. 796 To summarize, even if it we are unable to give precise numbers for 797 AKE frequency, a lightweight AKE: 799 * reduces the time for network formation and AKE runs in challenging 800 radio technologies, 802 * allows devices to quickly re-establish security in case of 803 reboots, and 805 * enables support for recommendations of frequent key renewal. 807 3. Requirements Summary 809 * The AKE must support PSK, RPK and certificate based authentication 810 with PFS and crypto agility for AKE as well as OSCORE, have 3 811 flights and support transport over CoAP. It is required to 812 support different schemes for transporting and identifying 813 credentials. 815 * After the AKE run, the peers must be mutually authenticated, agree 816 on a shared secret with PFS and good amount of randomness, peer 817 identifiers (potentially short), and COSE algorithms to use. 819 * The AKE must reuse CBOR, CoAP and COSE primitives and algorithms 820 for low code complexity and to avoid duplicate maintenance of a 821 combined OSCORE and AKE implementation. 823 * The messages should be as small as reasonably achievable. The 824 messages shall fit into as few LoRaWAN packets and 6TiSCH frames 825 as possible. 827 4. Security Considerations 829 This document compiles the requirements for an AKE and provides some 830 related security considerations. 832 The AKE must provide the security properties expected of IETF 833 protocols, e.g., providing mutual authentication, confidentiality, 834 and negotiation integrity as is further detailed in the requirements. 836 5. IANA Considerations 838 None. 840 Acknowledgments 842 The authors want to thank Richard Barnes, Karthik Bhargavan, Ivaylo 843 Petrov, Eric Rescorla, Michael Richardson, and Claes Tidestav for 844 providing valuable input. 846 Informative References 848 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 849 Constrained-Node Networks", RFC 7228, 850 DOI 10.17487/RFC7228, May 2014, 851 . 853 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 854 Bose, "Constrained Application Protocol (CoAP) Option for 855 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 856 August 2016, . 858 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 859 "Object Security for Constrained RESTful Environments 860 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 861 . 863 [I-D.ietf-6tisch-minimal-security] 864 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 865 "Constrained Join Protocol (CoJP) for 6TiSCH", Work in 866 Progress, Internet-Draft, draft-ietf-6tisch-minimal- 867 security-15, 10 December 2019, . 871 [I-D.ietf-lpwan-coap-static-context-hc] 872 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 873 Context Header Compression (SCHC) for CoAP", Work in 874 Progress, Internet-Draft, draft-ietf-lpwan-coap-static- 875 context-hc-12, 10 December 2019, . 879 [I-D.ietf-cose-x509] 880 Schaad, J., "CBOR Object Signing and Encryption (COSE): 881 Headers for carrying and referencing X.509 certificates", 882 Work in Progress, Internet-Draft, draft-ietf-cose-x509-05, 883 4 November 2019, . 886 [I-D.ietf-core-echo-request-tag] 887 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 888 Request-Tag, and Token Processing", Work in Progress, 889 Internet-Draft, draft-ietf-core-echo-request-tag-08, 4 890 November 2019, . 893 [I-D.irtf-cfrg-randomness-improvements] 894 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 895 and C. Wood, "Randomness Improvements for Security 896 Protocols", Work in Progress, Internet-Draft, draft-irtf- 897 cfrg-randomness-improvements-09, 27 January 2020, 898 . 901 [I-D.selander-ace-ake-authz] 902 Selander, G., Mattsson, J., Vucinic, M., and M. 903 Richardson, "Lightweight Authorization for Authenticated 904 Key Exchange.", Work in Progress, Internet-Draft, draft- 905 selander-ace-ake-authz-00, 6 February 2020, 906 . 909 [AKE-for-6TiSCH] 910 "AKE for 6TiSCH", March 2019, 911 . 914 [AKE-for-NB-IoT] 915 "AKE for NB-IoT", March 2019, 916 . 919 [NB-IoT-battery-life-evaluation] 920 "On mMTC, NB-IoT and eMTC battery life evaluation", 921 January 2017, 922 . 925 [HKDF] Krawczyk, H., "Cryptographic Extraction and Key 926 Derivation: The HKDF Scheme", May 2010, 927 . 929 [LwM2M] "OMA SpecWorks LwM2M", August 2018, 930 . 934 [Fairhair] "Security Architecture for the Internet of Things (IoT) in 935 Commercial Buildings, Fairhair Alliance white paper", 936 March 2018, . 940 [LoRaWAN] "LoRaWAN Regional Parameters v1.0.2rB", February 2017, 941 . 944 Authors' Addresses 946 Malisa Vucinic 947 Inria 949 Email: malisa.vucinic@inria.fr 951 Goeran Selander 952 Ericsson AB 954 Email: goran.selander@ericsson.com 955 John Preuss Mattsson 956 Ericsson AB 958 Email: john.mattsson@ericsson.com 960 Dan Garcia-Carrillo 961 Odin Solutions S.L. 963 Email: dgarcia@odins.es