idnits 2.17.1 draft-ietf-lake-reqs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 09, 2019) is 1597 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-14 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-08 == Outdated reference: A later version (-09) exists of draft-ietf-cose-x509-05 == Outdated reference: A later version (-19) exists of draft-ietf-lpwan-coap-static-context-hc-11 == Outdated reference: A later version (-14) exists of draft-irtf-cfrg-randomness-improvements-08 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: June 11, 2020 J. Mattsson 6 Ericsson AB 7 D. Garcia 8 Odin Solutions S.L. 9 December 09, 2019 11 Requirements for a Lightweight AKE for OSCORE 12 draft-ietf-lake-reqs-00 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 June 11, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Problem description . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. AKE for OSCORE . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Credentials . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 5 58 2.4. Crypto Agility and Security Properties . . . . . . . . . 6 59 2.5. Identity Protection . . . . . . . . . . . . . . . . . . . 7 60 2.6. Application Data . . . . . . . . . . . . . . . . . . . . 8 61 2.7. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 62 2.8. Denial of Service . . . . . . . . . . . . . . . . . . . . 9 63 2.9. Lightweight . . . . . . . . . . . . . . . . . . . . . . . 9 64 3. Requirements Summary . . . . . . . . . . . . . . . . . . . . 16 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 7. Informative References . . . . . . . . . . . . . . . . . . . 17 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 71 1. Introduction 73 OSCORE [RFC8613] is a lightweight communication security protocol 74 providing end-to-end security on application layer for constrained 75 IoT settings (cf. [RFC7228]). OSCORE lacks a matching authenticated 76 key exchange protocol (AKE). The intention with LAKE is to create a 77 simple yet secure AKE for implementation in embedded devices 78 supporting OSCORE. 80 To ensure that the AKE is efficient for the expected applications of 81 OSCORE, we list the relevant public specifications of technologies 82 where OSCORE is included: 84 o The IETF 6TiSCH WG charter (-02) identifies the need to "secur[e] 85 the join process and mak[e] that fit within the constraints of 86 high latency, low throughput and small frame sizes that 87 characterize IEEE802.15.4 TSCH". OSCORE protects the join 88 protocol as described in 6TiSCH Minimal Security 89 [I-D.ietf-6tisch-minimal-security]. 91 o The IETF LPWAN WG charter (-01) identifies the need to improve the 92 transport capabilities of LPWA networks such as NB-IoT and LoRa 93 whose "common traits include ... frame sizes ... [on] the order of 94 tens of bytes transmitted a few times per day at ultra-low 95 speeds". The application of OSCORE is described in 96 [I-D.ietf-lpwan-coap-static-context-hc]. 98 o OMA Specworks LwM2M version 1.1 [LwM2M] defines bindings to two 99 challenging radio technologies where OSCORE will be deployed: 100 LoRaWAN and NB-IoT. 102 Other industry fora which plan to use OSCORE: 104 o Fairhair Alliance has defined an architecture [Fairhair] which 105 adopts OSCORE for multicast, but it is not clear whether the 106 architecture will support unicast OSCORE. 108 o Open Connectivity Foundation (OCF) has been actively involved in 109 the OSCORE development for the purpose of deploying OSCORE, but no 110 public reference is available since OCF only references RFCs. We 111 believe that these OSCORE consumers reflect similar levels of 112 constraints on the devices and networks in question. 114 This document compiles the requirements for the AKE for OSCORE. It 115 summarizes the security requirements that are expected from such an 116 AKE, as well as the main characteristics of the environments where 117 the solution is envisioned to be deployed. The solution will 118 presumably be useful in other scenarios as well since a low security 119 overhead improves the overall performance. 121 2. Problem description 123 2.1. AKE for OSCORE 125 The rationale for designing this protocol is that OSCORE is lacking a 126 matching AKE. OSCORE was designed for lightweight RESTful operations 127 for example by minimizing the overhead, and applying the protection 128 to the application layer, thereby limiting the data being encrypted 129 and integrity protected for the other endpoint. Moreover, OSCORE was 130 tailored for use with lightweight primitives that are likely to be 131 implemented in the device, specifically CoAP, CBOR and COSE. The 132 same properties must apply to the AKE. 134 In order to be suitable for OSCORE, at the end of the AKE protocol 135 run the two parties must agree on (see Section 3.2 of [RFC8613]): 137 o a shared secret (OSCORE Master Secret) with PFS (see Section 2.3) 138 and a good amount of randomness. (The term "good amount of 139 randomness" is borrowed from [HKDF] to signify not necessarily 140 uniformly distributed randomness.) 142 o OSCORE Sender IDs of peer endpoints, arbitrarily short 143 o COSE algorithms to use with OSCORE 145 COSE provides the crypto primitives for OSCORE, and shall therefore 146 be used also by the AKE, for several reasons including maintenance of 147 crypto library. COSE provides identification of credentials and 148 algorithms for OSCORE and the AKE, and an extension point for new 149 schemes. 151 Moreover, the AKE must support transport over CoAP. Since the AKE 152 messages most commonly will be encapsulated in CoAP, the AKE must not 153 duplicate functionality provided by CoAP, or at least not duplicate 154 functionality in such a way that it adds extra costs in terms of code 155 size, code maintenance, etc. It is therefore assumed that the AKE is 156 being transported in a protocol that provides reliable transport, 157 that can preserve packet ordering and handle message duplication, 158 that can perform fragmentation and protect against denial of service 159 attacks, such as provided by the CoAP Echo option 160 [I-D.ietf-core-echo-request-tag]. 162 The AKE may use other transport than CoAP. In this case the 163 underlying layers must correspondingly handle message loss, 164 reordering, message duplication, fragmentation, and denial of service 165 protection. 167 2.2. Credentials 169 IoT deployments differ in terms of what credentials can be supported. 170 Currently many systems use pre-shared keys (PSKs) provisioned out of 171 band, for various reasons. PSKs are often used in a first deployment 172 because of their perceived simplicity. The use of PSKs allows for 173 protection of communication without major additional security 174 processing, and also enables the use of symmetric crypto algorithms 175 only, reducing the implementation and computational effort in the 176 endpoints. 178 However, PSK-based provisioning has inherent weaknesses. There has 179 been reports of massive breaches of PSK provisioning systems, and as 180 many systems use PSKs without perfect forward secrecy (PFS) they are 181 vulnerable to passive pervasive monitoring. The security of these 182 systems can be improved by adding PFS through an AKE authenticated by 183 the provisioned PSK. 185 Shared keys can alternatively be established in the endpoints using 186 an AKE protocol authenticated with asymmetric public keys instead of 187 symmetric secret keys. Raw public keys (RPK) can be provisioned with 188 the same scheme as PSKs, which allows for a more relaxed trust model 189 since RPKs need not be secret. The corresponding private keys are 190 assumed to be provisioned to the party being authenticated beforehand 191 (e.g. in factory or generated on-board). 193 As a third option, by using a public key infrastructure and running 194 an asymmetric key AKE with public key certificates instead of RPKs, 195 key provisioning can be omitted, leading to a more automated ("zero- 196 touch") bootstrapping procedure. The root CA keys are assumed to be 197 provisioned beforehand. 199 These steps provide an example of a migration path in limited scoped 200 steps from simple to more robust security bootstrapping and 201 provisioning schemes where each step improves the overall security 202 and/or simplicity of deployment of the IoT system, although not all 203 steps are necessarily feasible for the most constrained settings. 205 In order to allow for these different schemes, the AKE must support 206 PSK- (shared between two nodes), RPK- and certificate-based 207 authentication of the Diffie-Hellman (DH) key exchange. 209 Bandwidth is a scarce resource in constrained-node networks. The use 210 of static DH public keys instead of signature public keys is a 211 significant optimization and shall be supported. 213 To further minimize the bandwidth consumption it is required to 214 support transporting the certificates by reference rather than by 215 value. Considering the wide variety of deployments the AKE must 216 support different schemes for transporting and identifying 217 credentials, including those identified in Section 2 of 218 [I-D.ietf-cose-x509]. 220 The common lack of a user interface in constrained devices leads to 221 various credential provisioning schemes. The use of RPKs may be 222 appropriate for the authentication of the AKE initiator but not for 223 the AKE responder. The AKE must support different credentials for 224 authentication in different directions of the AKE run, e.g. 225 certificate-based authentication for the initiating endpoint and RPK- 226 based authentication for the responding endpoint. 228 Assuming that both signature public keys and static DH public keys 229 are in use, then also the case of mixed credentials need to be 230 supported with one endpoint using a static DH public key and the 231 other using a signature public key. 233 2.3. Mutual Authentication 235 The AKE must provide mutual authentication during the protocol run. 236 At the end of the AKE protocol, each endpoint shall have 237 authenticated the other. 239 The AKE cannot rely on messages being exchanged in both directions 240 after the AKE has completed, because CoAP/OSCORE requests may not 241 have a response [RFC7967]. Furthermore, there is no assumption of 242 dependence between CoAP client/server and AKE initiator/responder 243 roles, and an OSCORE context may be used with CoAP client and server 244 roles interchanged as is done e.g. in [LwM2M]. Since the protocol 245 may be initiated by different endpoints, it shall not be necessary to 246 determine beforehand which endpoint takes the role of initiator of 247 the AKE. 249 Compromise of initiator or responder long-term keys shall not enable 250 an attacker to compromise past session keys (Perfect Forward Secrecy) 251 and shall not enable a passive attacker to compromise future session 252 keys. These two properties can be achieved with an ephemeral Diffie- 253 Hellman key exchange. 255 To mitigate against bad random number generators the AKE shall 256 mandate randomness improvements such as 257 [I-D.irtf-cfrg-randomness-improvements] and analogously for symmetric 258 keys. 260 The AKE shall provide Key Compromise Impersonation (KCI) resistance. 262 The AKE shall protect against replay attacks (injective). 264 The endpoints shall be able to verify that the identity of the other 265 endpoint is an acceptable identity that it is intended to 266 authenticate to. The AKE shall protect against identity misbinding 267 attacks, when applicable. Note that the identity may be directly 268 related to a public key such as for example the public key itself, a 269 hash of 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 share 273 keys (cf. the Selfie attack on TLS 1.3) as that setting is out of 274 scope. 276 2.4. Crypto Agility and Security Properties 278 Motivated by long deployment lifetimes, the AKE is required to 279 support crypto agility, including modularity of COSE crypto 280 algorithms and negotiation of preferred crypto algorithms for OSCORE 281 and the AKE. 283 o The protocol shall support both pre-shared key and asymmetric key 284 authentication. PAKE and post-quantum key exchange is out of 285 scope, but may be supported in a later version. 287 o The protocol shall allow multiple elliptic curves for asymmetric 288 keys 290 o The AKE shall support negotiation of the all COSE algorithms used 291 in the AKE and that OSCORE supports. A successful negotiation 292 shall result in the most preferred algorithms of one of the 293 parties which are supported by the other. 295 o The AKE shall support different AEAD/MAC algorithms for AKE and 296 OSCORE 298 The AKE negotiation must be protected against downgrade attacks. 299 [Further detailing is requested.] 301 2.5. Identity Protection 303 In general, it is necessary to transport identities as part of the 304 AKE run in order to provide authentication of an entity not 305 identified beforehand. In the case of constrained devices, the 306 identity may contain sensitive information on the manufacturer of the 307 device, the batch, default firmware version, etc. Protecting 308 identifying information from passive and active attacks is important 309 from a privacy point of view, but needs to be balanced with the other 310 requirements, including security and lightweightness. For certain 311 data we therefore need to make an exemption in order to obtain an 312 efficient protocol. 314 The AKE is required to protect the identity against active attackers 315 of one of the peers and protection against passive attackers of the 316 other peer in the case of public key identities. 318 In case of a PSK identifier, this may be protected against passive 319 attackers with a key derived from the Diffie-Hellman shared secret. 320 The responder has first access to the shared secret but does in 321 general not know from whom a message without PSK identifier is sent. 322 Therefore the protection of PSK identifier in general needs to be 323 performed by the initiator, i.e. at the earliest in message 3. As a 324 consequence, in order to authenticate the responder within the AKE, 325 at least four protocol messages are needed in case of symmetric key 326 authentication with identity protection. Considering the need to 327 keep the number of messages at a minimum (see Section 2.9.4), unless 328 there are other good reasons for having more than 3 messages, it is 329 not required to protect the PSK identifier, and it may thus be sent 330 in the first message. 332 Other identifying information that needs to be transported in plain 333 text is cipher suites and connection identifiers. Encrypting crypto 334 algorithms does not allow negotiation of cipher suite within 3 335 messages. Encryption of connection identifiers only works in 336 asymmetric case and does not enable arbitrarily short identifiers 337 (see Section 2.1). 339 2.6. Application Data 341 In order to reduce round trips and number of messages, and in some 342 cases also streamline processing, certain applications may want to 343 transport application data within the AKE. 345 One example is the transport of third-party signed authorization 346 information such as an access token or a voucher from initiator to 347 responder or vice versa. Such a scheme could enable the party 348 receiving the authorization information to make a decision about 349 whether the party being authenticated is also authorized before the 350 protocol is completed, and if not discontinue the protocol before it 351 is complete, thereby saving time and message processing. 353 Another example is the embedding of certificate enrolment request or 354 a newly issued certificate. 356 The AKE must support the transport of application data within the 357 protocol messages. 359 It is expected that an AKE with 3 messages will provide the following 360 protection of the application data: 362 o Application data in the first message is unprotected 364 o Application data in the second message is confidentiality 365 protected against passive attackers and integrity protected 366 against active attackers 368 o Application data in the third message is confidentiality and 369 integrity protected against active attackers 371 Application data may contain privacy sensitive information. The 372 application data must not violate the AKE security properties. The 373 assumptions on the application data need to be detailed in the 374 specification of the AKE. 376 2.7. Extensibility 378 It is desirable that the AKE supports some kind of extensibility, in 379 particular, the ability to later include new AKE modes such as PAKE 380 support. Note that by supporting COSE, the AKE can already support 381 new algorithms, new certificate formats, ways to identify 382 credentials, etc. 384 Since the main objective with this work is to create a simple yet 385 secure AKE, care needs to be taken to avoid feature creep and 386 extensions working against this. 388 2.8. Denial of Service 390 The AKE shall protect against denial of service attacks on responder 391 and initiator to the extent that the protocol supports lightweight 392 deployments (see Section 2.9) and without duplicating the DoS 393 mitigation of the underlying transport (see Section 2.1). 395 Jamming attacks, cutting cables etc. leading to long term loss of 396 availability may not be possible to mitigate, but an attacker 397 temporarily injecting messages or disturbing the communication shall 398 not have a similar impact. 400 2.9. Lightweight 402 We target an AKE which is efficiently deployable in 6TiSCH multi-hop 403 networks, LoRaWAN networks and NB-IoT networks. The desire is to 404 optimize the AKE to be 'as lightweight as reasonably achievable' in 405 these environments, where 'lightweight' refers to: 407 o resource consumption, measured by bytes on the wire, wall-clock 408 time and number of round trips to complete, or power consumption 410 o the amount of new code required on end systems which already have 411 an OSCORE stack 413 These properties need to be considered in the context of the use of 414 an existing CoAP/OSCORE stack in the targeted networks and 415 technologies. Some properties are difficult to evaluate for a given 416 protocol, for example, because they depend on the radio conditions or 417 other simultaneous network traffic. Additionally, these properties 418 are not independent. Therefore the properties listed here should be 419 taken as input for identifying plausible protocol metrics that can be 420 more easily measured and compared between protocols. 422 Per 'bytes on the wire', it is desirable for the AKE messages to fit 423 into the MTU size of these protocols; and if not possible, within as 424 few frames as possible, since using multiple MTUs can have 425 significant costs in terms of time and power. Note that the MTU size 426 depends on radio technology and its characteristics, including data 427 rates, number of hops, etc. Example benchmarks are given further 428 down in this section. 430 Per 'time', it is desirable for the AKE message exchange(s) to 431 complete in a reasonable amount of time, both for a single 432 uncongested exchange and when multiple exchanges are running in an 433 interleaved fashion, like e.g. in a "network formation" setting when 434 multiple devices connect for the first time. This latency may not be 435 a linear function depending on congestion and the specific radio 436 technology used. As these are relatively low data rate networks, the 437 latency contribution due to computation is in general not expected to 438 be dominant. 440 Per 'round-trips', it is desirable that the number of completed 441 request/response message exchanges required before the initiating 442 endpoint can start sending protected traffic data is as small as 443 possible, since this reduces completion time. See Section 2.9.4 for 444 a discussion about the tradeoff between message size and number of 445 messages. 447 Per 'power', it is desirable for the transmission of AKE messages and 448 crypto to draw as little power as possible. The best mechanism for 449 doing so differs across radio technologies. For example, NB-IoT uses 450 licensed spectrum and thus can transmit at higher power to improve 451 coverage, making the transmitted byte count relatively more important 452 than for other radio technologies. In other cases, the radio 453 transmitter will be active for a full MTU frame regardless of how 454 much of the frame is occupied by message content, which makes the 455 byte count less sensitive for the power consumption. Increased power 456 consumption is unavoidable in poor network conditions, such as most 457 wide-area settings including LoRaWAN. 459 Per 'new code', it is desirable to introduce as little new code as 460 possible onto OSCORE-enabled devices to support this new AKE. These 461 devices have on the order of 10s of kB of memory and 100 kB of 462 storage on which an embedded OS; a COAP stack; CORE and AKE 463 libraries; and target applications would run. It is expected that 464 the majority of this space is available for actual application logic, 465 as opposed to the support libraries. In a typical OSCORE 466 implementation COSE encrypt and signature structures will be 467 available, as will support for COSE algorithms relevant for IoT 468 enabling the same algorithms as is used for OSCORE (e.g. COSE 469 algorithm no. 10 = CCM* used by 6TiSCH). The use of those, or CBOR 470 or CoAP, would not add to the footprint. 472 While the large variety of settings and capabilities of the devices 473 and networks makes it challenging to produce exact values of some 474 these dimensions, there are some key benchmarks that are tractable 475 for security protocol engineering and which have a significant 476 impact. 478 2.9.1. LoRaWAN 480 LoRaWAN employs unlicensed radio frequency bands in the 868 MHz ISM 481 band. As a case in point, we focus here on deployment in Europe, 482 where this is regulated by ETSI EN 300 220. For LoRaWAN the most 483 relevant metric is the Time-on-Air, which determines the back-off 484 times and can be used as an indicator to calculate energy 485 consumption. LoRaWAN is legally required to use a duty cycle with 486 values such as 0.1%, 1% and 10% depending on the sub-band that is 487 being used, leading to a payload split into fragments interleaved 488 with back-off times. For Europe, the duty cycle is 1% (or smaller). 489 Although there are exceptions from the use of duty cycle, the use of 490 an AKE for providing end-to-end security on application layer needs 491 to comply with the duty cycle. 493 2.9.1.1. Bytes on the wire 495 LoRaWAN has a variable MTU depending on the Spreading Factor (SF). 496 The higher the spreading factor, the higher distances can be achieved 497 and/or better reception. LoRaWAN has a header size of 13 bytes, to 498 which we have to add the maximum recommended payload depending on the 499 SF used. If the coverage and distance allows it, with SF7 - 500 corresponding to higher data rates - the maximum payload is 222 501 bytes. For a SF12 - and low data rates - the maximum payload is 51 502 bytes. 504 The benchmark used here is Data Rates 0-2 corresponding to a packet 505 size of 51 bytes [LoRaWAN]. The use of larger frame size depend on 506 good radio conditions which are not always present. Some libraries/ 507 providers only support 51-bytes packet size. 509 2.9.1.2. Time 511 The time it takes to send a message over the air in LoRaWAN can be 512 calculated as a function of the different parameters of the 513 communication. These are the Spreading Factor (SF), the message 514 size, the channel, bandwidth, coding rate, etc. An important feature 515 of LoRaWAN is the duty cycle limitation due to the use of the ISM 516 band. A duty cycle of 1% implies that the time to complete a 517 fragmentation of the payload increases by at least 10,000%. This 518 limitation determines how long time the device will have to wait for 519 next use, which encourages the reduction of the message size as much 520 as possible. 522 2.9.1.3. Round trips and number of messages 524 Considering the duty cycle of LoRaWAN and associated back-off times, 525 the round trips and number of messages needs to be reduced as much as 526 possible. 528 2.9.1.4. Power 530 The calculation of the power consumption in LoRaWAN is dependent on 531 several factors, such as the spreading factor used and the length of 532 the message sent, both having a clear dependency with the time it 533 takes to transmit the message. The communication model (inherent to 534 the different LoRaWAN classes of devices) also has an impact on the 535 energy consumption, but overall the Time-on-Air is an important 536 indication of the performance. 538 2.9.2. 6TiSCH 540 6TiSCH operates in the 2.4 GHz unlicensed frequency band and uses 541 hybrid Time Division/Frequency Division multiple access (TDMA/FDMA). 542 Nodes in a 6TiSCH network form a mesh. The basic unit of 543 communication, a cell, is uniquely defined by its time and frequency 544 offset in the communication schedule matrix. Cells can be assigned 545 for communication to a pair of nodes in the mesh and so be collision- 546 free, or shared by multiple nodes, for example during network 547 formation. In case of shared cells, some collision-resolution scheme 548 such as slotted-Aloha is employed. Nodes exchange frames which are 549 at most 127-bytes long, including the link-layer headers. To 550 preserve energy, the schedule is typically computed in such a way 551 that nodes switch on their radio below 1% of the time ("radio duty 552 cycle"). A 6TiSCH mesh can be several hops deep. In typical use 553 cases considered by the 6TiSCH working group, a network that is 2-4 554 hops deep is commonplace; a network which is more than 8 hops deep is 555 not common. 557 2.9.2.1. Bytes on the wire 559 Increasing the number of bytes on the wire in a protocol message has 560 an important effect on the 6TiSCH network in case the fragmentation 561 is triggered. More fragments contribute to congestion of shared 562 cells (and concomitant error rates) in a non-linear way. 564 The available size for key exchange messages depends on the topology 565 of the network, whether the message is traveling uplink or downlink, 566 and other stack parameters. A key performance indicator for a 6TiSCH 567 network is "network formation", i.e. the time it takes from switching 568 on all devices, until the last device has executed the AKE and 569 securely joined. As an example, given the size limit on the frames 570 and taking into account the different headers (including link-layer 571 security), if a 6TiSCH network is 5 hops deep, the maximum CoAP 572 payload size to avoid fragmentation is 47/45 bytes (uplink/downlink) 573 [AKE-for-6TiSCH]. 575 2.9.2.2. Time 577 Given the slotted nature of 6TiSCH, the number of bytes in a frame 578 has insignificant impact on latency, but the number of frames has. 579 The relevant metric for studying AKE is the network formation time, 580 which implies parallel AKE runs among nodes that are attempting to 581 join the network. Network formation time directly affects the time 582 installers need to spend on site at deployment time. 584 2.9.2.3. Round trips and number of messages 586 Given the mesh nature of the 6TiSCH network, and given that each 587 message may travel several hops before reaching its destination, it 588 is highly desirable to minimize the number of round trips to reduce 589 latency. 591 2.9.2.4. Power 593 From the power consumption point of view, it is more favorable to 594 send a small number of large frames than a larger number of short 595 frames. 597 2.9.3. NB-IoT 599 3GPP has specified Narrow-Band IoT (NB-IoT) for support of infrequent 600 data transmission via user plane and via control plane. NB-IoT is 601 built on cellular licensed spectrum at low data rates for the purpose 602 of supporting: 604 o operations in extreme coverage conditions, 606 o device battery life of 10 years or more, 608 o low device complexity and cost, and 610 o a high system capacity of millions of connected devices per square 611 kilometer. 613 NB-IoT achieves these design objectives by: 615 o Reduced baseband processing, memory and RF enabling low complexity 616 device implementation. 618 o A lightweight setup minimizing control signaling overhead to 619 optimize power consumption. 621 o In-band, guard-band, and stand-alone deployment enabling efficient 622 use of spectrum and network infrastructure. 624 2.9.3.1. Bytes on the wire 626 The number of bytes on the wire in a protocol message has a direct 627 effect on the performance for NB-IoT. In contrast to LoRaWAN and 628 6TiSCH, the NB-IoT radio bearers are not characterized by a fixed 629 sized PDU. Concatenation, segmentation and reassembly are part of 630 the service provided by the NB-IoT radio layer. As a consequence, 631 the byte count has a measurable impact on time and energy consumption 632 for running the AKE. 634 2.9.3.2. Time 636 Coverage significantly impacts the available bit rate and thereby the 637 time for transmitting a message, and there is also a difference 638 between downlink and uplink transmissions (see Section 2.9.3.4). The 639 transmission time for the message is essentially proportional to the 640 number of bytes. 642 Since NB-IoT is operating in licensed spectrum, in contrast to e.g. 643 LoRaWAN, the packets on the radio interface can be transmitted back- 644 to-back, so the time before sending OSCORE protected data is limited 645 by the number of round trips/messages of the AKE and not by a duty 646 cycle. 648 2.9.3.3. Round trips and number of messages 650 As indicated in Section 2.9.3.2, the number of messages and round- 651 trips is one limiting factor for protocol completion time. 653 2.9.3.4. Power 655 Since NB-IoT is operating in licensed spectrum, the device is allowed 656 to transmit at a relatively high power, which has a large impact on 657 the energy consumption. 659 The benchmark for NB-IoT energy consumption is based on the same 660 computational model as was used by 3GPP in the design of this radio 661 layer [NB-IoT-battery-life-evaluation]. The device power consumption 662 is assumed to be 500mW for transmission and 80mW for reception. 663 Power consumption for "light sleep" (~ 3mW) and "deep sleep" (~ 664 0.015mW) are negligible in comparison. The bitrates (uplink/ 665 downlink) are assumed to be 28/170 kbps for good coverage and 666 0,37/2,5 kbps for bad coverage. 668 The results [AKE-for-NB-IoT] show a high per-byte energy consumption 669 for uplink transmissions, in particular in bad coverage. Given that 670 the application decides about the device being initiator or responder 671 in the AKE, the protocol cannot be tailored for a particular message 672 being uplink or downlink. To perform well in both kind of 673 applications the overall number of bytes of the protocol needs to be 674 as low as possible. 676 2.9.4. Discussion 678 While "as small protocol messages as possible" does not lend itself 679 to a sharp boundary threshold, "as few protocol messages as possible" 680 does and is relevant in all settings above. 682 The penalty is high for not fitting into the frame sizes of 6TiSCH 683 and LoRaWAN networks. Fragmentation is not defined within these 684 technologies so requires fragmentation scheme on a higher layer in 685 the stack. With fragmentation increases the number of frames per 686 message, each with its associated overhead in terms of power 687 consumption and latency. Additionally the probability for errors 688 increases, which leads to retransmissions of frames or entire 689 messages that in turn increases the power consumption and latency. 691 There are trade-offs between "few messages" and "few frames"; if 692 overhead is spread out over more messages such that each message fits 693 into a particular frame this may reduce the overall power 694 consumption. While it may be possible to engineer such a solution 695 for a particular radio technology and signature algorithm, the 696 benefits in terms of fewer messages/round trips in general and for 697 NB-IoT in particular (see Section 2.9.3) are considered more 698 important than optimizing for a specific scenario. Hence an optimal 699 AKE protocol has 3 messages and each message fits into as few frames 700 as possible, ideally 1 frame per message. 702 The difference between uplink and downlink performance should not be 703 engineered into the protocol since it cannot be assumed that a 704 particular protocol message will be sent uplink or downlink. 706 2.9.5. AKE frequency 708 One question that has been asked in the context of lightweightness 709 is: - How often is the AKE executed? While it may be impossible to 710 give a precise answer there are other perspectives to this question. 712 1. For some use cases, already one execution of the AKE is heavy, 713 for example, because 715 * there are a number of parallel executions of the AKE which 716 loads down the network, such as in a network formation 717 setting, or 719 * the duty cycle makes the completion time long for even one run 720 of the protocol. 722 2. If a device reboots it may not be able to recover the security 723 context, e.g. due to lack of persistent storage, and is required 724 to establish a new security context for which an AKE is 725 preferred. Reboot frequency may be difficult to predict in 726 general. 728 3. To limit the impact of a key compromise, BSI, NIST and ANSSI and 729 other organizations recommend in other contexts frequent renewal 730 of keys by means of Diffie-Hellman key exchange. This may be a 731 symmetric key authenticated key exchange, where the symmetric key 732 is obtained from a previous asymmetric key based run of the AKE. 734 To summarize, even if it we are unable to give precise numbers for 735 AKE frequency, a lightweight AKE 737 o reduces the time for network formation and AKE runs in challenging 738 radio technologies, 740 o allows devices to quickly re-establish security in case of 741 reboots, and 743 o enables support for recommendations of frequent key renewal 745 3. Requirements Summary 747 o The AKE must support PSK, RPK and certificate based authentication 748 with PFS and crypto agility for AKE as well as OSCORE, be 3-pass 749 and support transport over CoAP. It is required to support 750 different schemes for transporting and identifying credentials. 752 o After the AKE run, the peers must be mutually authenticated, agree 753 on a shared secret with PFS and good amount of randomness, peer 754 identifiers (potentially short), and COSE algorithms to use. 756 o The AKE must reuse CBOR, CoAP and COSE primitives and algorithms 757 for low code complexity and to avoid duplicate maintenance of a 758 combined OSCORE and AKE implementation. 760 o The messages should be as small as reasonably achievable. The 761 messages shall fit into as few LoRaWAN packets and 6TiSCH frames 762 as possible. 764 4. Security Considerations 766 This document compiles the requirements for an AKE and provides some 767 related security considerations. 769 The AKE must provide the security properties expected of IETF 770 protocols, e.g., providing confidentiality protection, integrity 771 protection, and authentication as is further detailed in the 772 requirements. 774 5. IANA Considerations 776 None. 778 Acknowledgments 780 The authors want to thank Richard Barnes, Karthik Bhargavan, Eric 781 Rescorla, Michael Richardson, and Claes Tidestav for providing 782 valuable input. 784 7. Informative References 786 [AKE-for-6TiSCH] 787 "AKE for 6TiSCH", March 2019, 788 . 791 [AKE-for-NB-IoT] 792 "AKE for NB-IoT", March 2019, 793 . 796 [Fairhair] 797 "Security Architecture for the Internet of Things (IoT) in 798 Commercial Buildings, Fairhair Alliance white paper", 799 March 2018, . 803 [HKDF] Krawczyk, H., "Cryptographic Extraction and Key 804 Derivation: The HKDF Scheme", May 2010, 805 . 807 [I-D.ietf-6tisch-minimal-security] 808 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 809 "Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf- 810 6tisch-minimal-security-14 (work in progress), December 811 2019. 813 [I-D.ietf-core-echo-request-tag] 814 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 815 Request-Tag, and Token Processing", draft-ietf-core-echo- 816 request-tag-08 (work in progress), November 2019. 818 [I-D.ietf-cose-x509] 819 Schaad, J., "CBOR Object Signing and Encryption (COSE): 820 Headers for carrying and referencing X.509 certificates", 821 draft-ietf-cose-x509-05 (work in progress), November 2019. 823 [I-D.ietf-lpwan-coap-static-context-hc] 824 Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static 825 Context Header Compression (SCHC) for CoAP", draft-ietf- 826 lpwan-coap-static-context-hc-11 (work in progress), 827 October 2019. 829 [I-D.irtf-cfrg-randomness-improvements] 830 Cremers, C., Garratt, L., Smyshlyaev, S., Sullivan, N., 831 and C. Wood, "Randomness Improvements for Security 832 Protocols", draft-irtf-cfrg-randomness-improvements-08 833 (work in progress), November 2019. 835 [LoRaWAN] "LoRaWAN Regional Parameters v1.0.2rB", February 2017, 836 . 839 [LwM2M] "OMA SpecWorks LwM2M", August 2018, 840 . 844 [NB-IoT-battery-life-evaluation] 845 "On mMTC, NB-IoT and eMTC battery life evaluation", 846 January 2017, 847 . 850 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 851 Constrained-Node Networks", RFC 7228, 852 DOI 10.17487/RFC7228, May 2014, 853 . 855 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 856 Bose, "Constrained Application Protocol (CoAP) Option for 857 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 858 August 2016, . 860 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 861 "Object Security for Constrained RESTful Environments 862 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 863 . 865 Authors' Addresses 867 Malisa Vucinic 868 Inria 870 Email: malisa.vucinic@inria.fr 872 Goeran Selander 873 Ericsson AB 875 Email: goran.selander@ericsson.com 877 John Preuss Mattsson 878 Ericsson AB 880 Email: john.mattsson@ericsson.com 882 Dan Garcia-Carrillo 883 Odin Solutions S.L. 885 Email: dgarcia@odins.es