idnits 2.17.1 draft-seitz-ace-design-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.agl-tls-snapstart' is defined on line 541, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-01) exists of draft-bmoeller-tls-falsestart-00 -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group L. Seitz 3 Internet-Draft SICS Swedish ICT 4 Intended Status: Informational G. Selander 5 Expires: August 18, 2014 Ericsson 7 February 14, 2014 9 Design Considerations for Security Protocols in Constrained Environments 10 draft-seitz-ace-design-considerations-00 12 Abstract 14 Considerable effort has been spent on securing existing Internet 15 standard authentication and authorization protocols such as TLS, 16 Kerberos, and OAuth, among others. It would save a lot of effort if 17 these protocols could be profiled to be feasible for constrained 18 environments, with some easily obtainable security considerations. 20 However, these protocols were typically not designed with constrained 21 environments in mind, so profiling of an existing protocol may result 22 in a far from optimal solution. Moreover they are not necessarily 23 complying with their original design objectives outside their 24 intended domain of application. 26 This document examines the impact of typical characteristics of 27 security protocols (e.g. cryptographic calculations, number and size 28 of protocol messages) in a constrained environment. The goal is to 29 provide decision support when different resource usage optimizations 30 are possible in the adaptation of a security protocol for this 31 setting. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress". 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/1id-abstracts.html 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 Copyright and License Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Device assumptions . . . . . . . . . . . . . . . . . . . . 5 75 2.2 Relevant Factors . . . . . . . . . . . . . . . . . . . . . . 5 76 2.3 Security protocols in constrained environments . . . . . . . 6 77 3. Protocol design considerations . . . . . . . . . . . . . . . . 7 78 3.1 Straightforward optimizations . . . . . . . . . . . . . . . 7 79 3.1.1 Smaller messages . . . . . . . . . . . . . . . . . . . . 7 80 3.1.2 Fewer messages . . . . . . . . . . . . . . . . . . . . . 7 81 3.1.3 Less computations . . . . . . . . . . . . . . . . . . . 8 82 3.1.4 Reduce RAM usage . . . . . . . . . . . . . . . . . . . . 8 83 3.1.5 Reduce code size . . . . . . . . . . . . . . . . . . . . 8 84 3.2 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 3.2.1 Fewer vs smaller messages . . . . . . . . . . . . . . . 9 86 3.2.2 Crypto vs message exchange . . . . . . . . . . . . . . . 9 87 3.2.3 Transmitting vs receiving messages . . . . . . . . . . . 9 88 3.2.4 Distributing costs over deployment life time . . . . . . 10 89 3.2.5 Outsourcing heavy computations . . . . . . . . . . . . . 10 90 3.2.6 DoS mitigation and anti-spoofing in the Internet . . . . 10 91 3.2.7 Outsourcing key management . . . . . . . . . . . . . . . 11 92 3.2.8 Verifying authorization . . . . . . . . . . . . . . . . 11 94 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 95 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 97 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 99 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 102 1. Introduction 104 When adapting security protocols for constrained nodes, one has to 105 take into account the various resource limitations. While it might 106 be tempting to optimize the usage of a certain resource (e.g. 107 minimizing RAM consumption), such an approach might produce a less- 108 than-optimal overall solution, compared to a more holistic approach 109 that leverages the combined effect of different optimization 110 possibilities. 112 The goal of this document is to summarize some characteristics of 113 security protocols and weigh their impact against each other in order 114 to allow effective trade-offs when adapting existing protocols to a 115 constrained setting. While there is some overlap with the scope of 116 the Lightweight Implementation Guidance WG, this document is aimed 117 more at security protocol profiling and design than actual 118 implementation decisions that are the main focus of LWIG. 120 1.1 Terminology 122 Certain security-related terms are to be understood in the sense 123 defined in [RFC4949]. These terms include, but are not limited to, 124 "authentication", "authorization", "confidentiality", "encryption", 125 "data integrity", "message authentication code", and "verify". 127 Terminology for constrained environments is defined in [I-D.ietf- 128 lwig-terminology] e.g. "constrained device". 130 2. Background 132 We are assuming a multi-party protocol setting with at least the 133 following parties 135 a) a resource server hosting resources 136 b) a client seeking access to some resource, and 137 c) an authorization server acting Trusted Third Party (TTP) for 138 key distribution and access control handling. 140 The resource server and/or the client is assumed to be constrained, 141 but the authorization server is not. 143 The authorization server can provide authentication and authorization 144 means (e.g. cryptographic keys, access control information, 145 certificates) for the other parties. 147 There are various authentications and authorizations taking place in 148 this multi-party protocol. For example, the client and 149 authorization server mutually authenticates and and the client is 150 being authorized by the authorization server. The resource server 151 needs authenticate information provided by the authorization server, 152 based on a previously established relationship (e.g. shared symmetric 153 keys). Finally when the client communicates with the resource 154 server, the client's authorization needs to be verified, which might 155 include authentication of the client. 157 Note: Security protocols designed to handle authentication and 158 authorization between two mutually unknown less-constrained peers are 159 not necessarily adapted to the current setting, where optimizations 160 can be made by relying on an relatively unconstrained TTP. 162 2.1. Device assumptions 164 Devices may be constrained in different ways, as described in the 165 LWIG terminology document [I-D.ietf-lwig-terminology]. This work is 166 targeting class 1 devices, but may be applicable even the most 167 constrained class of devices (C0) if supported by relevant proxy 168 functionality. Class 2 devices probably do not need any special 169 considerations, since they can mostly support the same protocols as 170 unconstrained devices. 172 A device for which these considerations apply could e.g. run the 173 following protocol stack, potentially supported by a proxy: 175 o The application layer protocol is CoAP [I-D.ietf-core-coap], 176 using UDP at the transport layer. 177 o CoAP will be running on top of DTLS [RFC6347]. 178 o IPv6 [RFC4291] is assumed to be the Internet layer protocol on 179 top of the adaptation layer 6LoWPAN [RFC4944]. 180 o IEEE 802.15.4 [IEEE802] is assumed as the Link layer protocol 181 for wireless communication. We assume that a large proportion 182 of the target devices will communicate over wireless channels. 184 2.2 Relevant Factors 186 From the LWIG terminology draft [I-D.ietf-lwig-terminology] we can 187 list the following resources that need to be considered in general: 189 o RAM memory (required state and buffers for running protocols) 190 o Flash/ROM memory (required libraries and code complexity) 191 o Computational power (required processing speed) 192 o Electrical energy (battery consumption, if not mains-powered) 193 o User interface and physical accessibility (for performing manual 194 operations directly on the device) 195 o Network (bit rate, loss rate, dynamic topology, fragmentation, 196 lack of advanced services) 198 The consumers of these resources in the case of security protocols 199 can be summarized as follows: 201 o Cryptographic algorithms 202 - based on symmetric cryptography 203 - based on asymmetric cryptography 204 - (orthogonal) implemented by a co-processor (e.g. AES, SHA, 205 ECC) 206 o Composing/parsing protocol messages (e.g. Base64 en/decoding, 207 JSON, ASN.1, CBOR) 208 o Sending/receiving protocol messages 209 o Listening, while waiting to receive protocol messages 211 2.3 Security protocols in constrained environments 213 One of the potential advantages with extending basic Internet 214 Protocols to constrained nodes is that other standardized protocols 215 can be applied too. 217 In particular in the case of security protocols, there is a 218 considerable effort spent to eliminate flaws and weaknesses that 219 could otherwise be exploited for attacking the system. It would save 220 a lot of effort if it was possible to profile these protocols for 221 running efficiently in a constrained environment while maintaining 222 their security properties. 224 However, the profiling of a protocol may result in a far from optimal 225 solution. For example assume that a constrained profile of a 226 security protocol is made by reducing the message sizes. Such a 227 protocol may still be badly suited for constrained devices e.g. 228 because the number of round trips is what makes the latency high, and 229 reducing that would essentially change the security properties of the 230 protocol. 232 Moreover, as many of these protocols were not designed for a 233 constrained environment, they are not necessarily complying with 234 their original design objectives outside their intended domain of 235 application. Even security objectives that applied to the Internet 236 may be violated: e.g. a DoS mitigation measure that is based on a 237 processing commitment by a client (a "puzzle", see e.g. [RFC5201]) 238 may be inappropriate if the server is much more constrained than the 239 client. 241 This memo is intended to support the adaptation of an existing 242 security protocol for a constrained environment by providing some 243 considerations on resource consumption. Furthermore this memo 244 documents the assumptions that were made as a basis for these 245 considerations. 247 3. Protocol design considerations 249 3.1 Straightforward optimizations 251 This section lists some potential targets for resource optimizations. 253 3.1.1 Smaller messages 255 Reducing message size will reduce composing/parsing and 256 sending/receiving costs which is favorably impacting energy 257 consumption and latency. Some specific considerations: 259 o Smaller than CoAP payload size (1024 bytes) avoids fragmentation 260 at the application layer. 261 o Smaller than the maximum MAC-layer frame size (e.g. 127 bytes 262 for IEEE 802.15.4) avoids fragmentation at the link layer. 263 o The largest messages are potentially those containing 264 certificates or authorization tokens, so reducing their size 265 significantly will have a large impact. 267 3.1.2 Fewer messages 269 Removing message exchanges or round trips have potentially large 270 impact on energy consumption and latency. 272 Reducing the number of messages in a given security protocol is in 273 general not possible without changing the essential security 274 properties of the protocol. Experiments by Google with TLS false 275 start [I-D.bmoeller-tls-falsestart] and TLS snap start [I-D.agl-tls- 276 snapstart] illustrate the difficulty of trying to reduce the number 277 of messages in an established security protocol. 279 Challenge-response based authentication protocols may potentially be 280 replaced with other protocols with alternative measures to ensure 281 freshness, such as time or sequence numbers. Such an approach would 282 require fewer message passes, but ensuring freshness can be 283 problematic, since some constrained devices may not be able to 284 reliably measure time. 286 On the other hand, there are long lifetime battery powered IEEE 287 802.15.4e devices implementing Time Slotted Channel Hopping (TSCH) 288 which has good time synchronization properties, since that is 289 required for communication. 291 3.1.3 Less computations 293 One way of reducing the complexity of required computations is to 294 reduce the number of public key operations used during normal 295 operations, e.g. by keeping existing sessions alive, or generating 296 session resumption state on a less constrained device. The drawback 297 in this case is that either more RAM or more sending and receiving of 298 messages are needed. 300 An alternative is to replace public key operations with symmetric key 301 operations. Significant reductions in resource consumption can be 302 achieved by using symmetric cryptography instead of asymmetric 303 cryptography, since asymmetric cryptography generally requires larger 304 libraries (e.g. BigInteger, elliptic curves), and consumes more RAM, 305 processing power and energy than symmetric algorithms. 307 However, it is not always possible to make this replacement as some 308 of the properties of asymmetric cryptography, such as non-repudiation 309 of signatures, and non-confidential key distribution do not apply for 310 symmetric keys. It may require a change in trust model, where a TTP 311 is assumed e.g. for key management. 313 3.1.4 Reduce RAM usage 315 Reducing the usage of RAM memory can be achieved by reducing the size 316 of variable state information required by a protocol. Different 317 security protocols and -modes have different requirements in this 318 respect. Optimizations may potentially be done by profiling certain 319 options of the protocol to predefined, default values. 321 Another possibility is to simplify parsing and processing of protocol 322 messages, leading to smaller libraries that need to be loaded into 323 memory. Further the size of the protocol messages, e.g. certificates 324 and authorization tokens, directly affects the size of the buffers 325 that need to be allocated for receiving and sending them, so keeping 326 them small also helps. 328 3.1.5 Reduce code size 330 The overall size of the code is influenced mainly by the size of the 331 libraries needed for cryptography and parsing messages (ASN.1, JSON, 332 XML). In general asymmetric cryptography requires larger libraries 333 (e.g. BigInteger, Elliptic curves) than symmetric cryptography. 334 Minimal libraries for parsing ASN.1 and JSON are roughly comparable 335 in size (around 6 kB) while even minimal XML parsers generally have a 336 significantly larger size. 338 3.2 Trade-offs 340 This section looks at the more difficult question how to weigh 341 different optimizations against each other. We emphasize in this 342 section the potential role of the authorization server as an enabler 343 for some of the optimizations. 345 3.2.1 Fewer vs smaller messages 347 When comparing reduction of message size versus sending fewer 348 messages in total, if one takes into account the overhead of setting 349 up a bearer, it is more efficient to send longer messages than 350 shorter messages. Considering fragmentation it is better to send 351 messages shorter than the fragmentation limit. Therefore optimal 352 message size seems to be just below the fragmentation limit. Note 353 that fragmentation carries an additional performance penalty in 354 excess of just adding the overhead of sending several fragments, 355 since fragmenting a message increases the risk that a fragment is 356 lost and that the message as a whole needs to be retransmitted. 358 3.2.2 Crypto vs message exchange 360 It is known that in wireless constrained devices, the energy 361 consumption for sending and receiving messages is high, and 362 significantly higher than symmetric crypto operations [Margi10impact] 363 and [Meu08engery]. Hence if it is possible to send fewer messages at 364 the cost of delegating some symmetric crypto to the constrained 365 device, such a trade off is favorable. The potential drawback is 366 increased latency and code size. The latter could probably be 367 avoided by reusing existing symmetric algorithms that are needed 368 anyway. 370 Results from [Meu08engery] indicate that energy consumption for 371 public key operations is on par or greater than message exchange for 372 a particular security protocol. However, the efficiency of 373 processing is increasing: The processing power follows Moore's law 374 (up to point) and depends on the manufacturing technology while the 375 transmission/reception power is based on laws of physics laws that 376 don't change with manufacturing. So processing will be more and more 377 energy efficient (up to a point) while the transmission/reception 378 remains almost stable in terms of energy efficiency. 380 3.2.3 Transmitting vs receiving messages 382 Results comparing energy consumption of transmitting versus receiving 383 messages seem contradictory. While [Margi10impact] indicates that 384 receiving a message is much cheaper in energy consumption, than 385 sending, [Meu08engery] seems to suggest that both costs are roughly 386 on par. 388 An important point from [Meu08engery] is that one should consider the 389 cost of listening for the next message in a protocol, while the other 390 party is performing some computations. It is not obvious how much 391 impact smart listening techniques such as Low Power Listening (LPL) 392 or X-MAC [Bue06xmac] have. 394 Our conclusion on this issue is that is warrants further 395 investigation in order to determine whether it should influence 396 protocol design and profiling or not. 398 3.2.4 Distributing costs over deployment life time 400 Provisioning (e.g. access control lists) has a cost which potentially 401 may be amortized over the lifetime of a deployment. Security 402 protocol establishment (e.g. DTLS handshake) may similarly have a 403 high cost that but can be acceptable, if the established session can 404 be used for a long time. The drawback is that storage or RAM memory 405 is consumed to save the state of the provisioned data or the 406 established protocol. 408 3.2.5 Outsourcing heavy computations 410 A method of saving computational effort is to outsource computations 411 to a less constrained TTP e.g. authorization decisions and policy 412 management to the authorization server. Note however that this may 413 be changing the trust model of the original protocol, and if the 414 constrained device needs the result of the outsourced computation, 415 this information must be transported in a secure way which in turn 416 incurs a non-negligible cost. 418 3.2.6 DoS mitigation and anti-spoofing in the Internet 420 As we have seen it is important in a wireless constrained environment 421 to restrict the number of messages sent and received in a protocol. 423 Some Internet security protocols include DoS mitigation or anti- 424 spoofing mechanisms such as cookies (cf. [RFC6347]) or puzzles (cf. 425 [RFC5201]) which adds message size and/or round trips. These 426 mechanisms were in general not designed for a constrained environment 427 and may potentially make the protocol unnecessarily heavy without 428 efficiently providing the desired effect. 430 In fact the existence of a TTP allows for more efficient mechanisms, 431 e.g. that a client first commits or proves source address to the 432 authorization server which can assert such properties in an 433 authorization token verified by a constrained server. 435 3.2.7 Outsourcing key management 437 Securing communication between two mutually unknown less-constrained 438 peers has a high cost in terms of additional round trips, e.g. to 439 protect against requests from spoofed initiators, DoS mitigation, 440 challenge response protocols etc. In addition, both parties are 441 often contributing to the generation of key material, which requires 442 exchange of data used in key generation. These costs are a 443 consequence of the trust model and is clearly not adapted to the 444 current setting, where optimizations can be made by relying on an 445 relatively unconstrained authorization server. 447 In addition to providing authorization decisions, the authorization 448 server may support authentication and authorization between resource 449 server and client by e.g. 451 o providing symmetric keys to support authentication (cf. 452 Kerberos). 453 o providing protected assertions containing statements about 454 client and server, including public key certificates. 456 3.2.8 Verifying authorization 458 As noted above, it is desirable to verify authorization of a request 459 as early as possible in a protocol, to reduce unnecessary message 460 exchanges and processing. However, if that involves verifying a 461 digital signature, then the operation is in itself heavily resource 462 consuming and would preferably only take place after it is known that 463 the request is authorized. This is obviously a "catch 22" and there 464 are various options to attempt to design around this. 466 In the present case, where we assume a TTP with a previously 467 established relationship - say a shared symmetric key - with the 468 resource server, the legitimacy of the request may e.g. be indicated 469 with a Message Authentication Code instead of a digital signature 470 over an authorization decision. 472 Authentication of client and server may still require verification of 473 digital signature if public keys are used. However, as noted above, 474 the authorization server may also support key distribution and 475 provide symmetric keys for authentication (cf. Kerberos). 477 4. Security Considerations 479 This memo deals with design considerations for security protocols, 480 including security trade-offs that can be made to save resources, 481 some of which will come at the cost of weakening security. 483 Since a security protocol itself consume resources, one factor that 484 needs to be taken into consideration is the possibility for attackers 485 to use these very security protocols in order to mount a denial of 486 service attack. 488 Each profiled or modified security protocol must bear its own 489 security considerations. Protocol designers need to carefully 490 evaluate the feasibility of stronger (and thus more resource 491 consuming) security against the risks incurred by a weaker security 492 that is more easy to implement or execute on a constrained node. 494 5. IANA Considerations 496 This document has no actions for IANA. 498 6. Acknowledgements The authors would like to thank Sumit Shingal and 499 Vlasios Tsiatsis for contributing to the discussion and giving 500 helpful comments. 502 7. References 504 7.1 Normative References 506 [I-D.ietf-core-coap] 507 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 508 "Constrained Application Protocol (CoAP)", draft-ietf- 509 core-coap-18 (work in progress), June 2013. 511 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 512 Architecture", RFC 4291, February 2006. 514 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 515 "Transmission of IPv6 Packets over IEEE 802.15.4 516 Networks", RFC 4944, September 2007. 518 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 519 36, RFC 4949, August 2007. 521 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 522 Security Version 1.2", RFC 6347, January 2012. 524 7.2 Informative References 526 [I-D.ietf-lwig-terminology] 527 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 528 Constrained Node Networks", draft-ietf-lwig-terminology-07 529 (work in progress), February 2014. 531 [IEEE802] 532 IEEE Computer Society, "IEEE Standard for Local and 533 metropolitan area networks Part 15.4: Low-Rate Wireless 534 Personal 536 [I-D.bmoeller-tls-falsestart] 537 Langley, A., Modadugu, N., and B. Moeller, "Transport 538 Layer Security (TLS) False Start", draft-bmoeller-tls- 539 falsestart-00 (expired draft), June 2010. 541 [I-D.agl-tls-snapstart] 542 Langley, A., "Transport Layer Security (TLS) Snap Start", 543 draft-agl-tls-snapstart-00 (expired draft), June 2010. 545 [Meu08engery] 546 Meulenaer, G., Gosset ,F., Standaert, F., and L. 547 Vandendorpe, "On the Energy Cost of Communication and 548 Cryptography in Wireless Sensor Networks", proceedings of 549 the IEEE International Conference on Wireless and Mobile 550 Computing, 2008. 552 [Margi10impact] 553 Margi, C., Oliveira, B., Sousa, G., Simplicio, M., 554 Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, 555 "Impact of Operating Systmes on Wireless Sensor Networks 556 (Security) Applications and Testbeds", proceedings of the 557 19th International Conference on Computer Communications 558 and Networks (ICCCN), 2010. 560 [Bue06xmac] 561 Buettner, M., Yee, G., Anderson, E., and R. Han, "X-MAC: A 562 Short Preamble MAC Protocol for Duty-Cycled Wireless 563 Sensor Networks", proceedings of SenSys'06, 2006 565 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. 566 Henderson, "Host Identity Protocol", RFC 5201, April 2008. 568 Authors' Addresses 570 Ludwig Seitz 571 SICS Swedish ICT AB 572 Scheelevagen 17 573 22370 Lund 574 SWEDEN 575 EMail: ludwig@sics.se 577 Goeran Selander 578 Ericsson 579 Farogatan 6 580 16480 Kista 581 SWEDEN 582 EMail: goran.selander@ericsson.com