CoRE Working Group L. Seitz Internet-Draft SICS Swedish ICT Intended Status: Informational G. Selander Expires: August 18, 2014 Ericsson February 14, 2014 Design Considerations for Security Protocols in Constrained Environments draft-seitz-ace-design-considerations-00 Abstract Considerable effort has been spent on securing existing Internet standard authentication and authorization protocols such as TLS, Kerberos, and OAuth, among others. It would save a lot of effort if these protocols could be profiled to be feasible for constrained environments, with some easily obtainable security considerations. However, these protocols were typically not designed with constrained environments in mind, so profiling of an existing protocol may result in a far from optimal solution. Moreover they are not necessarily complying with their original design objectives outside their intended domain of application. This document examines the impact of typical characteristics of security protocols (e.g. cryptographic calculations, number and size of protocol messages) in a constrained environment. The goal is to provide decision support when different resource usage optimizations are possible in the adaptation of a security protocol for this setting. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Seitz & Selander Expires August 18, 2014 [Page 1] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Device assumptions . . . . . . . . . . . . . . . . . . . . 5 2.2 Relevant Factors . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Security protocols in constrained environments . . . . . . . 6 3. Protocol design considerations . . . . . . . . . . . . . . . . 7 3.1 Straightforward optimizations . . . . . . . . . . . . . . . 7 3.1.1 Smaller messages . . . . . . . . . . . . . . . . . . . . 7 3.1.2 Fewer messages . . . . . . . . . . . . . . . . . . . . . 7 3.1.3 Less computations . . . . . . . . . . . . . . . . . . . 8 3.1.4 Reduce RAM usage . . . . . . . . . . . . . . . . . . . . 8 3.1.5 Reduce code size . . . . . . . . . . . . . . . . . . . . 8 3.2 Trade-offs . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.1 Fewer vs smaller messages . . . . . . . . . . . . . . . 9 3.2.2 Crypto vs message exchange . . . . . . . . . . . . . . . 9 3.2.3 Transmitting vs receiving messages . . . . . . . . . . . 9 3.2.4 Distributing costs over deployment life time . . . . . . 10 3.2.5 Outsourcing heavy computations . . . . . . . . . . . . . 10 3.2.6 DoS mitigation and anti-spoofing in the Internet . . . . 10 3.2.7 Outsourcing key management . . . . . . . . . . . . . . . 11 3.2.8 Verifying authorization . . . . . . . . . . . . . . . . 11 Seitz & Selander Expires August 18, 2014 [Page 2] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Seitz & Selander Expires August 18, 2014 [Page 3] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 1. Introduction When adapting security protocols for constrained nodes, one has to take into account the various resource limitations. While it might be tempting to optimize the usage of a certain resource (e.g. minimizing RAM consumption), such an approach might produce a less- than-optimal overall solution, compared to a more holistic approach that leverages the combined effect of different optimization possibilities. The goal of this document is to summarize some characteristics of security protocols and weigh their impact against each other in order to allow effective trade-offs when adapting existing protocols to a constrained setting. While there is some overlap with the scope of the Lightweight Implementation Guidance WG, this document is aimed more at security protocol profiling and design than actual implementation decisions that are the main focus of LWIG. 1.1 Terminology Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "confidentiality", "encryption", "data integrity", "message authentication code", and "verify". Terminology for constrained environments is defined in [I-D.ietf- lwig-terminology] e.g. "constrained device". 2. Background We are assuming a multi-party protocol setting with at least the following parties a) a resource server hosting resources b) a client seeking access to some resource, and c) an authorization server acting Trusted Third Party (TTP) for key distribution and access control handling. The resource server and/or the client is assumed to be constrained, but the authorization server is not. The authorization server can provide authentication and authorization means (e.g. cryptographic keys, access control information, certificates) for the other parties. There are various authentications and authorizations taking place in this multi-party protocol. For example, the client and Seitz & Selander Expires August 18, 2014 [Page 4] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 authorization server mutually authenticates and and the client is being authorized by the authorization server. The resource server needs authenticate information provided by the authorization server, based on a previously established relationship (e.g. shared symmetric keys). Finally when the client communicates with the resource server, the client's authorization needs to be verified, which might include authentication of the client. Note: Security protocols designed to handle authentication and authorization between two mutually unknown less-constrained peers are not necessarily adapted to the current setting, where optimizations can be made by relying on an relatively unconstrained TTP. 2.1. Device assumptions Devices may be constrained in different ways, as described in the LWIG terminology document [I-D.ietf-lwig-terminology]. This work is targeting class 1 devices, but may be applicable even the most constrained class of devices (C0) if supported by relevant proxy functionality. Class 2 devices probably do not need any special considerations, since they can mostly support the same protocols as unconstrained devices. A device for which these considerations apply could e.g. run the following protocol stack, potentially supported by a proxy: o The application layer protocol is CoAP [I-D.ietf-core-coap], using UDP at the transport layer. o CoAP will be running on top of DTLS [RFC6347]. o IPv6 [RFC4291] is assumed to be the Internet layer protocol on top of the adaptation layer 6LoWPAN [RFC4944]. o IEEE 802.15.4 [IEEE802] is assumed as the Link layer protocol for wireless communication. We assume that a large proportion of the target devices will communicate over wireless channels. 2.2 Relevant Factors From the LWIG terminology draft [I-D.ietf-lwig-terminology] we can list the following resources that need to be considered in general: o RAM memory (required state and buffers for running protocols) o Flash/ROM memory (required libraries and code complexity) o Computational power (required processing speed) o Electrical energy (battery consumption, if not mains-powered) o User interface and physical accessibility (for performing manual operations directly on the device) o Network (bit rate, loss rate, dynamic topology, fragmentation, Seitz & Selander Expires August 18, 2014 [Page 5] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 lack of advanced services) The consumers of these resources in the case of security protocols can be summarized as follows: o Cryptographic algorithms - based on symmetric cryptography - based on asymmetric cryptography - (orthogonal) implemented by a co-processor (e.g. AES, SHA, ECC) o Composing/parsing protocol messages (e.g. Base64 en/decoding, JSON, ASN.1, CBOR) o Sending/receiving protocol messages o Listening, while waiting to receive protocol messages 2.3 Security protocols in constrained environments One of the potential advantages with extending basic Internet Protocols to constrained nodes is that other standardized protocols can be applied too. In particular in the case of security protocols, there is a considerable effort spent to eliminate flaws and weaknesses that could otherwise be exploited for attacking the system. It would save a lot of effort if it was possible to profile these protocols for running efficiently in a constrained environment while maintaining their security properties. However, the profiling of a protocol may result in a far from optimal solution. For example assume that a constrained profile of a security protocol is made by reducing the message sizes. Such a protocol may still be badly suited for constrained devices e.g. because the number of round trips is what makes the latency high, and reducing that would essentially change the security properties of the protocol. Moreover, as many of these protocols were not designed for a constrained environment, they are not necessarily complying with their original design objectives outside their intended domain of application. Even security objectives that applied to the Internet may be violated: e.g. a DoS mitigation measure that is based on a processing commitment by a client (a "puzzle", see e.g. [RFC5201]) may be inappropriate if the server is much more constrained than the client. This memo is intended to support the adaptation of an existing security protocol for a constrained environment by providing some Seitz & Selander Expires August 18, 2014 [Page 6] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 considerations on resource consumption. Furthermore this memo documents the assumptions that were made as a basis for these considerations. 3. Protocol design considerations 3.1 Straightforward optimizations This section lists some potential targets for resource optimizations. 3.1.1 Smaller messages Reducing message size will reduce composing/parsing and sending/receiving costs which is favorably impacting energy consumption and latency. Some specific considerations: o Smaller than CoAP payload size (1024 bytes) avoids fragmentation at the application layer. o Smaller than the maximum MAC-layer frame size (e.g. 127 bytes for IEEE 802.15.4) avoids fragmentation at the link layer. o The largest messages are potentially those containing certificates or authorization tokens, so reducing their size significantly will have a large impact. 3.1.2 Fewer messages Removing message exchanges or round trips have potentially large impact on energy consumption and latency. Reducing the number of messages in a given security protocol is in general not possible without changing the essential security properties of the protocol. Experiments by Google with TLS false start [I-D.bmoeller-tls-falsestart] and TLS snap start [I-D.agl-tls- snapstart] illustrate the difficulty of trying to reduce the number of messages in an established security protocol. Challenge-response based authentication protocols may potentially be replaced with other protocols with alternative measures to ensure freshness, such as time or sequence numbers. Such an approach would require fewer message passes, but ensuring freshness can be problematic, since some constrained devices may not be able to reliably measure time. On the other hand, there are long lifetime battery powered IEEE 802.15.4e devices implementing Time Slotted Channel Hopping (TSCH) which has good time synchronization properties, since that is required for communication. Seitz & Selander Expires August 18, 2014 [Page 7] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 3.1.3 Less computations One way of reducing the complexity of required computations is to reduce the number of public key operations used during normal operations, e.g. by keeping existing sessions alive, or generating session resumption state on a less constrained device. The drawback in this case is that either more RAM or more sending and receiving of messages are needed. An alternative is to replace public key operations with symmetric key operations. Significant reductions in resource consumption can be achieved by using symmetric cryptography instead of asymmetric cryptography, since asymmetric cryptography generally requires larger libraries (e.g. BigInteger, elliptic curves), and consumes more RAM, processing power and energy than symmetric algorithms. However, it is not always possible to make this replacement as some of the properties of asymmetric cryptography, such as non-repudiation of signatures, and non-confidential key distribution do not apply for symmetric keys. It may require a change in trust model, where a TTP is assumed e.g. for key management. 3.1.4 Reduce RAM usage Reducing the usage of RAM memory can be achieved by reducing the size of variable state information required by a protocol. Different security protocols and -modes have different requirements in this respect. Optimizations may potentially be done by profiling certain options of the protocol to predefined, default values. Another possibility is to simplify parsing and processing of protocol messages, leading to smaller libraries that need to be loaded into memory. Further the size of the protocol messages, e.g. certificates and authorization tokens, directly affects the size of the buffers that need to be allocated for receiving and sending them, so keeping them small also helps. 3.1.5 Reduce code size The overall size of the code is influenced mainly by the size of the libraries needed for cryptography and parsing messages (ASN.1, JSON, XML). In general asymmetric cryptography requires larger libraries (e.g. BigInteger, Elliptic curves) than symmetric cryptography. Minimal libraries for parsing ASN.1 and JSON are roughly comparable in size (around 6 kB) while even minimal XML parsers generally have a significantly larger size. Seitz & Selander Expires August 18, 2014 [Page 8] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 3.2 Trade-offs This section looks at the more difficult question how to weigh different optimizations against each other. We emphasize in this section the potential role of the authorization server as an enabler for some of the optimizations. 3.2.1 Fewer vs smaller messages When comparing reduction of message size versus sending fewer messages in total, if one takes into account the overhead of setting up a bearer, it is more efficient to send longer messages than shorter messages. Considering fragmentation it is better to send messages shorter than the fragmentation limit. Therefore optimal message size seems to be just below the fragmentation limit. Note that fragmentation carries an additional performance penalty in excess of just adding the overhead of sending several fragments, since fragmenting a message increases the risk that a fragment is lost and that the message as a whole needs to be retransmitted. 3.2.2 Crypto vs message exchange It is known that in wireless constrained devices, the energy consumption for sending and receiving messages is high, and significantly higher than symmetric crypto operations [Margi10impact] and [Meu08engery]. Hence if it is possible to send fewer messages at the cost of delegating some symmetric crypto to the constrained device, such a trade off is favorable. The potential drawback is increased latency and code size. The latter could probably be avoided by reusing existing symmetric algorithms that are needed anyway. Results from [Meu08engery] indicate that energy consumption for public key operations is on par or greater than message exchange for a particular security protocol. However, the efficiency of processing is increasing: The processing power follows Moore's law (up to point) and depends on the manufacturing technology while the transmission/reception power is based on laws of physics laws that don't change with manufacturing. So processing will be more and more energy efficient (up to a point) while the transmission/reception remains almost stable in terms of energy efficiency. 3.2.3 Transmitting vs receiving messages Results comparing energy consumption of transmitting versus receiving messages seem contradictory. While [Margi10impact] indicates that receiving a message is much cheaper in energy consumption, than sending, [Meu08engery] seems to suggest that both costs are roughly Seitz & Selander Expires August 18, 2014 [Page 9] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 on par. An important point from [Meu08engery] is that one should consider the cost of listening for the next message in a protocol, while the other party is performing some computations. It is not obvious how much impact smart listening techniques such as Low Power Listening (LPL) or X-MAC [Bue06xmac] have. Our conclusion on this issue is that is warrants further investigation in order to determine whether it should influence protocol design and profiling or not. 3.2.4 Distributing costs over deployment life time Provisioning (e.g. access control lists) has a cost which potentially may be amortized over the lifetime of a deployment. Security protocol establishment (e.g. DTLS handshake) may similarly have a high cost that but can be acceptable, if the established session can be used for a long time. The drawback is that storage or RAM memory is consumed to save the state of the provisioned data or the established protocol. 3.2.5 Outsourcing heavy computations A method of saving computational effort is to outsource computations to a less constrained TTP e.g. authorization decisions and policy management to the authorization server. Note however that this may be changing the trust model of the original protocol, and if the constrained device needs the result of the outsourced computation, this information must be transported in a secure way which in turn incurs a non-negligible cost. 3.2.6 DoS mitigation and anti-spoofing in the Internet As we have seen it is important in a wireless constrained environment to restrict the number of messages sent and received in a protocol. Some Internet security protocols include DoS mitigation or anti- spoofing mechanisms such as cookies (cf. [RFC6347]) or puzzles (cf. [RFC5201]) which adds message size and/or round trips. These mechanisms were in general not designed for a constrained environment and may potentially make the protocol unnecessarily heavy without efficiently providing the desired effect. In fact the existence of a TTP allows for more efficient mechanisms, e.g. that a client first commits or proves source address to the authorization server which can assert such properties in an authorization token verified by a constrained server. Seitz & Selander Expires August 18, 2014 [Page 10] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 3.2.7 Outsourcing key management Securing communication between two mutually unknown less-constrained peers has a high cost in terms of additional round trips, e.g. to protect against requests from spoofed initiators, DoS mitigation, challenge response protocols etc. In addition, both parties are often contributing to the generation of key material, which requires exchange of data used in key generation. These costs are a consequence of the trust model and is clearly not adapted to the current setting, where optimizations can be made by relying on an relatively unconstrained authorization server. In addition to providing authorization decisions, the authorization server may support authentication and authorization between resource server and client by e.g. o providing symmetric keys to support authentication (cf. Kerberos). o providing protected assertions containing statements about client and server, including public key certificates. 3.2.8 Verifying authorization As noted above, it is desirable to verify authorization of a request as early as possible in a protocol, to reduce unnecessary message exchanges and processing. However, if that involves verifying a digital signature, then the operation is in itself heavily resource consuming and would preferably only take place after it is known that the request is authorized. This is obviously a "catch 22" and there are various options to attempt to design around this. In the present case, where we assume a TTP with a previously established relationship - say a shared symmetric key - with the resource server, the legitimacy of the request may e.g. be indicated with a Message Authentication Code instead of a digital signature over an authorization decision. Authentication of client and server may still require verification of digital signature if public keys are used. However, as noted above, the authorization server may also support key distribution and provide symmetric keys for authentication (cf. Kerberos). 4. Security Considerations This memo deals with design considerations for security protocols, including security trade-offs that can be made to save resources, some of which will come at the cost of weakening security. Seitz & Selander Expires August 18, 2014 [Page 11] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 Since a security protocol itself consume resources, one factor that needs to be taken into consideration is the possibility for attackers to use these very security protocols in order to mount a denial of service attack. Each profiled or modified security protocol must bear its own security considerations. Protocol designers need to carefully evaluate the feasibility of stronger (and thus more resource consuming) security against the risks incurred by a weaker security that is more easy to implement or execute on a constrained node. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements The authors would like to thank Sumit Shingal and Vlasios Tsiatsis for contributing to the discussion and giving helpful comments. Seitz & Selander Expires August 18, 2014 [Page 12] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 7. References 7.1 Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf- core-coap-18 (work in progress), June 2013. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 7.2 Informative References [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-07 (work in progress), February 2014. [IEEE802] IEEE Computer Society, "IEEE Standard for Local and metropolitan area networks Part 15.4: Low-Rate Wireless Personal [I-D.bmoeller-tls-falsestart] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", draft-bmoeller-tls- falsestart-00 (expired draft), June 2010. [I-D.agl-tls-snapstart] Langley, A., "Transport Layer Security (TLS) Snap Start", draft-agl-tls-snapstart-00 (expired draft), June 2010. [Meu08engery] Meulenaer, G., Gosset ,F., Standaert, F., and L. Vandendorpe, "On the Energy Cost of Communication and Seitz & Selander Expires August 18, 2014 [Page 13] INTERNET DRAFT AAA Design Considerations for CoRE February 14, 2014 Cryptography in Wireless Sensor Networks", proceedings of the IEEE International Conference on Wireless and Mobile Computing, 2008. [Margi10impact] Margi, C., Oliveira, B., Sousa, G., Simplicio, M., Barreto, P., Carvalho, T., Naeslund, M., and R. Gold, "Impact of Operating Systmes on Wireless Sensor Networks (Security) Applications and Testbeds", proceedings of the 19th International Conference on Computer Communications and Networks (ICCCN), 2010. [Bue06xmac] Buettner, M., Yee, G., Anderson, E., and R. Han, "X-MAC: A Short Preamble MAC Protocol for Duty-Cycled Wireless Sensor Networks", proceedings of SenSys'06, 2006 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. Authors' Addresses Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN EMail: ludwig@sics.se Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com Seitz & Selander Expires August 18, 2014 [Page 14]