Internet DRAFT - draft-seitz-ace-design-considerations

draft-seitz-ace-design-considerations



 



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]