ACE Working Group                                              S. Gerdes
Internet-Draft                                   Universitaet Bremen TZI
Intended status: Informational                                  L. Seitz
Expires: May 18, 2018                                          RISE SICS
                                                             G. Selander
                                                                Ericsson
                                                         C. Bormann, Ed.
                                                 Universitaet Bremen TZI
                                                       November 14, 2017


     An architecture for authorization in constrained environments
                        draft-ietf-ace-actors-06

Abstract

   Constrained-node networks are networks where some nodes have severe
   constraints on code size, state memory, processing capabilities, user
   interface, power and communication bandwidth (RFC 7228).

   This document provides terminology, and identifies the elements that
   an architecture needs to address, providing a problem statement, for
   authentication and authorization in these networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on May 18, 2018.

Copyright Notice

   Copyright (c) 2017 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



Gerdes, et al.            Expires May 18, 2018                  [Page 1]


Internet-Draft                 ace-actors                  November 2017


   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Architecture and High-level Problem Statement . . . . . . . .   6
     2.1.  Elements of an Architecture . . . . . . . . . . . . . . .   6
     2.2.  Architecture Variants . . . . . . . . . . . . . . . . . .   9
     2.3.  Information Flows . . . . . . . . . . . . . . . . . . . .  11
   3.  Security Objectives . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  End-to-End Security Objectives in Multi-Hop Scenarios . .  13
   4.  Authentication and Authorization  . . . . . . . . . . . . . .  14
   5.  Actors and their Tasks  . . . . . . . . . . . . . . . . . . .  16
     5.1.  Constrained Level Actors  . . . . . . . . . . . . . . . .  17
     5.2.  Principal Level Actors  . . . . . . . . . . . . . . . . .  18
     5.3.  Less-Constrained Level Actors . . . . . . . . . . . . . .  18
   6.  Kinds of Protocols  . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Constrained Level Protocols . . . . . . . . . . . . . . .  19
       6.1.1.  Cross Level Support Protocols . . . . . . . . . . . .  20
     6.2.  Less-Constrained Level Protocols  . . . . . . . . . . . .  20
   7.  Elements of a Solution  . . . . . . . . . . . . . . . . . . .  20
     7.1.  Authorization . . . . . . . . . . . . . . . . . . . . . .  20
     7.2.  Authentication  . . . . . . . . . . . . . . . . . . . . .  21
     7.3.  Communication Security  . . . . . . . . . . . . . . . . .  22
     7.4.  Cryptographic Keys  . . . . . . . . . . . . . . . . . . .  22
   8.  Assumptions and Requirements  . . . . . . . . . . . . . . . .  23
     8.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  23
     8.2.  Constrained Devices . . . . . . . . . . . . . . . . . . .  24
     8.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .  25
     8.4.  Server-side Authorization . . . . . . . . . . . . . . . .  25
     8.5.  Client-side Authorization Information . . . . . . . . . .  25
     8.6.  Server-side Authorization Information . . . . . . . . . .  26
     8.7.  Resource Access . . . . . . . . . . . . . . . . . . . . .  26
     8.8.  Keys and Cipher Suites  . . . . . . . . . . . . . . . . .  27
     8.9.  Network Considerations  . . . . . . . . . . . . . . . . .  27
     8.10. Legacy Considerations . . . . . . . . . . . . . . . . . .  27
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  28
     9.1.  Physical Attacks on Sensor and Actuator Networks  . . . .  28
     9.2.  Clocks and Time Measurements  . . . . . . . . . . . . . .  29
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   11. Informative References  . . . . . . . . . . . . . . . . . . .  30



Gerdes, et al.            Expires May 18, 2018                  [Page 2]


Internet-Draft                 ace-actors                  November 2017


   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  32
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1.  Introduction

   As described in [RFC7228], constrained nodes are small devices with
   limited abilities which in many cases are made to fulfill a specific
   simple task.  They may have limited hardware resources such as
   processing power, memory, non-volatile storage and transmission
   capacity and additionally in most cases do not have user interfaces
   and displays.  Due to these constraints, commonly used security
   protocols are not always easily applicable, or may give rise to
   particular deployment/management challenges.

   As components of the Internet of Things (IoT), constrained nodes are
   expected to be integrated in all aspects of everyday life and thus
   will be entrusted with vast amounts of data.  Without appropriate
   security mechanisms attackers might gain control over things relevant
   to our lives.  Authentication and authorization mechanisms are
   therefore prerequisites for a secure Internet of Things.

   Applications generally require some degree of authentication and
   authorization, which gives rise to some complexity.  Authorization is
   about who can do what to which objects (see also [RFC4949]).
   Authentication specifically addresses the who, but is often specific
   to the authorization that is required (for example, it may be
   sufficient to authenticate the age of an actor, so no identifier is
   needed or even desired).  Authentication often involves credentials,
   only some of which need to be long-lived and generic; others may be
   directed towards specific authorizations (but still possibly long-
   lived).  Authorization then makes use of these credentials, as well
   as other information (such as the time of day).  This means that the
   complexity of authenticated authorization can often be moved back and
   forth between these two aspects.

   In some cases authentication and authorization can be addressed by
   static configuration provisioned during manufacturing or deployment
   by means of fixed trust anchors and static access control lists.
   This is particularly applicable to siloed, fixed-purpose deployments.

   However, as the need for flexible access to assets already deployed
   increases, the legitimate set of authorized entities as well as their
   specific privileges cannot be conclusively defined during deployment,
   without any need for change during the lifetime of the device.
   Moreover, several use cases illustrate the need for fine-grained
   access control policies, for which for instance a basic access
   control list concept may not be sufficiently powerful [RFC7744].




Gerdes, et al.            Expires May 18, 2018                  [Page 3]


Internet-Draft                 ace-actors                  November 2017


   The limitations of the constrained nodes impose a need for security
   mechanisms which take the special characteristics of constrained
   environments into account; not all constituents may be able to
   perform all necessary tasks by themselves.  To put it the other way
   round: the security mechanisms that protect constrained nodes must
   remain effective and manageable despite the limitations imposed by
   the constrained environment.

   Therefore, in order to be able to achieve complex security objectives
   between actors some of which are hosted on simple ("constrained")
   devices, some of the actors will make use of help from other, less
   constrained actors.  (This offloading is not specific to networks
   with constrained nodes, but their constrainedness as the main
   motivation is.)

   We therefore group the logical functional entities by whether they
   can be assigned to a constrained device ("constrained level") or need
   higher function platforms ("less-constrained level"); the latter does
   not necessarily mean high-function, "server" or "cloud" platforms.
   Note that assigning a logical functional entity to the constrained
   level does not mean that the specific implementation needs to be
   constrained, only that it _can_ be.

   The description assumes that some form of setup (aspects of which are
   often called provisioning and/or commissioning) has already been
   performed and at least some initial security relationships important
   for making the system operational have already been established.

   This document provides some terminology, and identifies the elements
   an architecture needs to address, representing the relationships
   between the logical functional entities involved; on this basis, a
   problem description for authentication and authorization in
   constrained-node networks is provided.

1.1.  Terminology

   Readers are assumed to be familiar with the terms and concepts
   defined in [RFC4949], including "authentication", "authorization",
   "confidentiality", "(data) integrity", "message authentication code",
   and "verify".

   REST terms including "resource", "representation", etc. are to be
   understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter
   also defines additional terms such as "endpoint".

   Terminology for constrained environments including "constrained
   device", "constrained-node network", "class 1", etc. is defined in
   [RFC7228].



Gerdes, et al.            Expires May 18, 2018                  [Page 4]


Internet-Draft                 ace-actors                  November 2017


   In addition, this document uses the following terminology:

   Resource (R):  an item of interest which is represented through an
      interface.  It might contain sensor or actuator values or other
      information.  (Intended to coincide with the definitions of
      [RFC7252] and [RFC7231].)

   Constrained node:  a constrained device in the sense of [RFC7228].

   Actor:  A logical functional entity that performs one or more tasks.
      Multiple actors may be present within a single device or a single
      piece of software.

   Resource Server (RS):  An entity which hosts and represents a
      Resource.  (Used here to discuss the server that provides a
      resource that is the end, not the means, of the authenticated
      authorization process - i.e., not CAS or AS.)

   Client (C):  An entity which attempts to access a resource on a RS.
      (Used to discuss the client whose access to a resource is the end,
      not the means, of the authenticated authorization process.)

   Principal:  (Used in its English sense here, and specifically as:) An
      individual that is either RqP or RO or both.

   Resource Owner (RO):  The principal that is in charge of the resource
      and controls its access permissions.

   Requesting Party (RqP):  The principal that is in charge of the
      Client and controls the requests a Client makes and its acceptance
      of responses.

   Authorization Server (AS):  An entity that prepares and endorses
      authentication and authorization data for a Resource Server.

   Client Authorization Server (CAS):  An entity that prepares and
      endorses authentication and authorization data for a Client.

   Authorization Manager:  An entity that prepares and endorses
      authentication and authorization data for a constrained node.
      Used in constructions such as "a constrained node's authorization
      manager" to denote AS for RS and CAS for C.

   Authenticated Authorization:  The confluence of mechanisms for
      authentication and authorization, ensuring that authorization is
      applied to and made available for authenticated entities and that
      entities providing authentication services are authorized to do so
      for the specific authorization process at hand.



Gerdes, et al.            Expires May 18, 2018                  [Page 5]


Internet-Draft                 ace-actors                  November 2017


   Note that other authorization architectures such as OAuth [RFC6749]
   or UMA [I-D.hardjono-oauth-umacore] focus on the authorization
   problems on the RS side, in particular what accesses to resources the
   RS is to allow.  In this document the term authorization includes
   this aspect, but is also used for the client-side aspect of
   authorization, i.e., more generally allowing RqPs to decide what
   interactions clients may perform with other endpoints.

2.  Architecture and High-level Problem Statement

   This document deals with how to control and protect resource-based
   interaction between potentially constrained endpoints.  The following
   setting is assumed as a high-level problem statement:

   o  An endpoint may host functionality of one or more actors.

   o  C in one endpoint requests to access R on a RS in another
      endpoint.

   o  A priori, the endpoints do not necessarily have a pre-existing
      security relationship to each other.

   o  Either of the endpoints, or both, may be constrained.

2.1.  Elements of an Architecture

   In its simplest expression, the architecture starts with a two-layer
   model: the principal level (at which components are assumed to be
   functionally unconstrained) and the constrained level (at which some
   functional constraints are assumed to apply to the components).

   Without loss of generality, we focus on the C functionality in one
   endpoint, which we therefore also call C, accessing the RS
   functionality in another endpoint, which we therefore also call RS.

   The constrained level and its security objectives are detailed in
   Section 5.1.

           --------------                          --------------
           |  -------   |                          |  -------   |
           |  |  C  | ------ requests resource -----> | RS  |   |
           |  ------- <----- provides resource ------ -------   |
           |  Endpoint  |                          |  Endpoint  |
           --------------                          --------------

                        Figure 1: Constrained Level





Gerdes, et al.            Expires May 18, 2018                  [Page 6]


Internet-Draft                 ace-actors                  November 2017


   The authorization decisions at the endpoints are made on behalf of
   the principals that control the endpoints.  To reuse OAuth and UMA
   terminology, the present document calls the principal that is
   controlling C the Requesting Party (RqP), and calls the principal
   that is controlling RS the Resource Owner (RO).  Each principal makes
   authorization decisions (possibly encapsulating them into security
   policies) which are then enforced by the endpoint it controls.

   The specific security objectives will vary, but for any specific
   version of this scenario will include one or more of:

   o  Objectives of type 1: No entity not authorized by the RO has
      access to (or otherwise gains knowledge of) R.

   o  Objectives of type 2: C is exchanging information with (sending a
      request to, accepting a response from) a resource only where it
      can ascertain that RqP has authorized the exchange with R.

   Objectives of type 1 require performing authorization on the Resource
   Server side while objectives of type 2 require performing
   authorization on the Client side.

   More on the security objectives of the principal level in
   Section 5.2.

     -------                           -------
     | RqP |                           |  RO | Principal Level
     -------                           -------
        |                                 |
   in charge of                      in charge of
        |                                 |
        V                                 V
     -------                           -------
     |  C  |  -- requests resource --> | RS  | Constrained Level
     -------  <-- provides resource--  -------

              Figure 2: Constrained Level and Principal Level

   The use cases defined in [RFC7744] demonstrate that constrained
   devices are often used for scenarios where their principals are not
   present at the time of the communication, are not able to communicate
   directly with the device because of a lack of user interfaces or
   displays, or may prefer the device to communicate autonomously.

   Moreover, constrained endpoints may need support with tasks requiring
   heavy processing, large memory or storage, or interfacing to humans,
   such as management of security policies defined by a principal.  The




Gerdes, et al.            Expires May 18, 2018                  [Page 7]


Internet-Draft                 ace-actors                  November 2017


   principal, in turn, requires some agent maintaining the policies
   governing how its endpoints will interact.

   For these reasons, another level of nodes is introduced in the
   architecture, the less-constrained level (illustrated below in
   Figure 3).  Using OAuth terminology, AS acts on behalf of the RO to
   control and support the RS in handling access requests, employing a
   pre-existing security relationship with RS.  We complement this with
   CAS acting on behalf of RqP to control and support the C in making
   resource requests and acting on the responses received, employing a
   pre-existing security relationship with C.  To further relieve the
   constrained level, authorization (and related authentication)
   mechanisms may be employed between CAS and AS (Section 6.2).  (Again,
   both CAS and AS are conceptual entities controlled by their
   respective principals.  Many of these entities, often acting for
   different principals, can be combined into a single server
   implementation; this of course requires proper segregation of the
   control information provided by each principal.)

    -------                           -------
    | RqP |                           |  RO | Principal Level
    -------                           -------
       |                                 |
   controls                          controls
       |                                 |
       V                                 V
   --------                          -------
   |  CAS |  <- AuthN and AuthZ ->   |  AS |  Less-Constrained Level
   --------                          -------
       |                                 |
   controls and supports        controls and supports
   authentication               authentication
   and authorization            and authorization
       |                                 |
       V                                 V
    -------                           -------
    |  C  |  -- requests resource --> | RS  | Constrained Level
    -------  <-- provides resource--  -------

                      Figure 3: Overall architecture

   Figure 3 shows all three levels considered in this document.  Note
   that the vertical arrows point down to illustrate exerting control
   and providing support; this is complemented by information flows that
   often are bidirectional.  Note also that not all entities need to be
   ready to communicate at any point in time; for instance, RqP may have
   provided enough information to CAS that CAS can autonomously
   negotiate access to RS with AS for C based on this information.



Gerdes, et al.            Expires May 18, 2018                  [Page 8]


Internet-Draft                 ace-actors                  November 2017


2.2.  Architecture Variants

   The elements of the architecture described above are indeed
   architectural; that is, they are parts of a conceptual model, and may
   be instantiated in various ways in practice.  For example, in a given
   scenario, several elements might share a single device or even be
   combined in a single piece of software.  If C is located on a more
   powerful device, it can be combined with CAS:

      -------                          --------
      | RqP |                          |  RO  |   Principal Level
      -------                          --------
        |                                  |
   in charge of                       in charge of
        |                                  |
        V                                  V
   ------------                        --------
   |  CAS + C | <- AuthN and AuthZ ->  |  AS  |  Less-Constrained Level
   ------------                        --------
               ^                            |
                \__                         |
                   \___                 authentication
                       \___             and authorization
        requests resource/ \___          support
        provides resource      \___        |
                                   \___    |
                                       V   V
                                        -------
                                        | RS  | Constrained Level
                                        -------


                       Figure 4: Combined C and CAS

   If RS is located on a more powerful device, it can be combined with
   AS:















Gerdes, et al.            Expires May 18, 2018                  [Page 9]


Internet-Draft                 ace-actors                  November 2017


      -------                            -------
      | RqP |                            |  RO |   Principal Level
      -------                            -------
        |                                  |
   in charge of                       in charge of
        |                                  |
        V                                  V
   ----------                        -----------
   |  CAS   | <- AuthN and AuthZ ->  | RS + AS |  Less-Constrained Level
   ----------                        -----------
        |                           ^
   authentication               ___/
   and authorization        ___/
   support              ___/ request resource / provides resource
        |           ___/
        V       ___/
     -------   /
     |  C  | <-
     -------


                       Figure 5: Combined AS and RS

   If C and RS have the same principal, CAS and AS can be combined.

                   ------------
                   | RqP = RO |   Principal Level
                   ------------
                         |
                     in charge of
                         |
                         V
                 --------------
                 |  CAS + AS  |  Less-Constrained Level
                 --------------
                /                \
               /                  \
   authentication               authentication
   and authorization            and authorization
   support                      support
            /                        \
           V                          V
     -------                          -------
     |  C  | -- requests resource --> | RS  | Constrained Level
     ------- <-- provides resource -- -------


                      Figure 6: CAS combined with AS



Gerdes, et al.            Expires May 18, 2018                 [Page 10]


Internet-Draft                 ace-actors                  November 2017


2.3.  Information Flows

   We now formulate the problem statement in terms of the information
   flows the architecture focuses on.  (While the previous section
   discusses the architecture in terms of abstract devices and their
   varying roles, the actual protocols being standardized define those
   information flows and the messages embodying them: "RESTful
   architectures focus on defining interfaces and not components"
   ([REST], p. 116).)

   The interaction with the nodes on the principal level, RO and RqP, is
   not involving constrained nodes and therefore can employ an existing
   mechanism.  The less-constrained nodes, CAS and AS, support the
   constrained nodes, C and RS, with control information, for example
   permissions of clients, conditions on resources, attributes of client
   and resource servers, keys and credentials.  This control information
   may be rather different for C and RS.

   The potential information flows are shown in Figure 7.  The direction
   of the vertical arrows expresses the exertion of control; actual
   information flow is bidirectional.

   The message flow may pass unprotected paths and thus need to be
   protected, potentially beyond a single REST hop (Section 3.1):

     -------                                     -------
     | CAS |                                     | AS  |
     -------                                     -------
     a ^ | b   a = requests for control info     a ^ | b
       | |     b = control information             | |
       | v                                         | v
     -------                                     -------
     | C   | ------ request -------------------> | RS  |
     |     | <----- response ------------------- |     |
     -------                                     -------


           Figure 7: Information flows that need to be protected

   o  We assume that the necessary keys/credentials for protecting the
      control information between the potentially constrained nodes and
      their associated less-constrained nodes are pre-established, for
      example as part of the commissioning procedure.

   o  Any necessary keys/credentials for protecting the interaction
      between the potentially constrained nodes will need to be
      established and maintained as part of a solution.




Gerdes, et al.            Expires May 18, 2018                 [Page 11]


Internet-Draft                 ace-actors                  November 2017


   In terms of the elements of the architecture laid out above, this
   document's problem statement for authorization in constrained
   environments can then be summarized as follows:

   o  The interaction between potentially constrained endpoints is
      controlled by control information provided by less-constrained
      nodes on behalf of the principals of the endpoints.

   o  The interaction between the endpoints needs to be secured, as well
      as the establishment of the necessary keys for securing the
      interaction, potentially end-to-end through intermediary nodes.

   o  The mechanism for transferring control information needs to be
      secured, potentially end-to-end through intermediary nodes.  Pre-
      established keying material may need to be employed for
      establishing the keys used to protect these information flows.

   (Note that other aspects relevant to secure constrained node
   communication such as secure bootstrap or group communication are not
   specifically addressed by the present document.)

3.  Security Objectives

   The security objectives that are addressed by an authorization
   solution include confidentiality and integrity.  Additionally, an
   authorization solution has an impact on the availability: First, by
   reducing the load (only accepting selected operations by selected
   entities limits the burden on system resources), and second, because
   misconfigured or wrongly designed authorization solutions can result
   in availability breaches (denial of service) as users might no longer
   be able to use data and services as they are supposed to.

   Authentication mechanisms can help achieve additional security
   objectives such as accountability and third-party verifiability.
   These additional objectives are not directly related to authorization
   and thus are not in scope of this draft, but may nevertheless be
   relevant.  Accountability and third-party verifiability may require
   authentication on a device level, if it is necessary to determine
   which device performed an action.  In other cases it may be more
   important to find out who is responsible for the device's actions.
   (The ensuing requirements for logging, auditability, and the related
   integrity requirements are very relevant for constrained devices as
   well, but outside the scope of this document.)  See also Section 4
   for more discussion about authentication and authorization.

   The security objectives and their relative importance differ for the
   various constrained environment applications and use cases [RFC7744].




Gerdes, et al.            Expires May 18, 2018                 [Page 12]


Internet-Draft                 ace-actors                  November 2017


   The architecture is based on the observation that different parties
   may have different security objectives.  There may also be a
   "collaborative" dimension: to achieve a security objective of one
   party, another party may be required to provide a service.  For
   example, if RqP requires the integrity of representations of a
   resource R that RS is hosting, both C and RS need to partake in
   integrity-protecting the transmitted data.  Moreover, RS needs to
   protect any write access to this resource as well as to relevant
   other resources (such as configuration information, firmware update
   resources) to prevent unauthorized users from manipulating R.

3.1.  End-to-End Security Objectives in Multi-Hop Scenarios

   In many cases, the information flows described in Section 2.3 cross
   multiple client-server pairings but still need to be protected end-
   to-end.  For example, AS may not be connected to RS (or may not want
   to exercise such a connection), relying on C for transferring
   authorization information.  As the authorization information is
   related to the permissions granted to C, C must not be in a position
   to manipulate this information, which therefore requires integrity
   protection on the way between AS and RS.

   As another example, resource representations sent between endpoints
   may be stored in intermediary nodes, such as caching proxies or pub-
   sub brokers.  Where these intermediaries cannot be relied on to
   fulfill the security objectives of the endpoints, it is the endpoints
   that will need to protect the exchanges beyond a single client-server
   exchange.

   Note that there may also be cases of intermediary nodes that very
   much partake in the security objectives to be achieved.  The question
   what are the pairs of endpoints between which the communication needs
   end-to-end protection (and which aspect of protection) is defined by
   the specific use case.  Two examples of intermediary nodes executing
   security functionality:

   o  To enable a trustworthy publication service, a pub-sub broker may
      be untrusted with the plaintext content of a publication
      (confidentiality), but required to verify that the publication is
      performed by claimed publisher and is not a replay of an old
      publication (authenticity/integrity).

   o  To comply with requirements of transparency, a gateway may be
      allowed to read, verify (authenticity) but not modify (integrity)
      a resource representation which therefore also is end-to-end
      integrity protected from the server towards a client behind the
      gateway.




Gerdes, et al.            Expires May 18, 2018                 [Page 13]


Internet-Draft                 ace-actors                  November 2017


   In order to support the required communication and application
   security, keying material needs to be established between the
   relevant nodes in the architecture.

4.  Authentication and Authorization

   Server-side authorization solutions aim at protecting the access to
   items of interest, for instance hardware or software resources or
   data: They enable the resource owner to control who can access it and
   how.

   To determine if an entity is authorized to access a resource, an
   authentication mechanism is needed.  According to the Internet
   Security Glossary [RFC4949], authentication is "the process of
   verifying a claim that a system entity or system resource has a
   certain attribute value."  Examples for attribute values are the ID
   of a device, the type of the device or the name of its owner.

   The security objectives the authorization mechanism aims at can only
   be achieved if the authentication and the authorization mechanism
   work together correctly.  We speak of authenticated authorization to
   refer to the required synthesis of mechanisms for authentication and
   authorization.

   Where used for authorization, the set of authenticated attributes
   must be meaningful for this purpose, i.e., authorization decisions
   must be possible based on these attributes.  If the authorization
   policy assigns permissions to an individual entity, the set of
   authenticated attributes must be suitable to uniquely identify this
   entity.

   In scenarios where devices are communicating autonomously there is
   often less need to uniquely identify an individual device: For a
   principal, the fact that a device belongs to a certain company or
   that it has a specific type (such as a light bulb) or location may be
   more important than that it has a unique identifier.

   (As a special case for the authorization of read access to a
   resource, RS may allow everyone to access an encrypted representation
   of the resource [OSCAR].  In this case, controlling read access to
   that resource can be reduced to controlling read access to the key;
   partially removing future access requires that the resource
   representation is re-encrypted and the new key is made available to
   all participants that are still authorized.)

   Principals (RqP and RO) need to decide about the required level of
   granularity for the authorization.  For example, we distinguish
   device authorization from owner authorization, and flat authorization



Gerdes, et al.            Expires May 18, 2018                 [Page 14]


Internet-Draft                 ace-actors                  November 2017


   from unrestricted authorization.  In the first case different access
   permissions are granted to individual devices while in the second
   case individual owners are authorized.  If flat authorization is
   used, all authenticated entities are implicitly authorized and have
   the same access permissions.  Unrestricted authorization for an item
   of interest means that no authorization mechanism is used for
   accessing this resource (not even by authentication) and all entities
   are able to access the item as they see fit (note that an
   authorization mechanism may still be used to arrive at the decision
   to employ unrestricted authorization).

   +-----------------+-------------------------------------------------+
   | Authorization   | Authorization is contingent on:                 |
   | granularity     |                                                 |
   +-----------------+-------------------------------------------------+
   | device          | authentication of specific device               |
   |                 |                                                 |
   | owner           | (authenticated) authorization by owner          |
   |                 |                                                 |
   | flat            | (any) authentication                            |
   |                 |                                                 |
   | unrestricted    | (unrestricted access; access always authorized) |
   +-----------------+-------------------------------------------------+

            Table 1: Some granularity levels for authorization

   More fine-grained authorization does not necessarily provide more
   security but can be more flexible.  Principals need to consider that
   an entity should only be granted the permissions it really needs
   (principle of least privilege), to ensure the confidentiality and
   integrity of resources.

   Client-side authorization solutions aim at protecting the client from
   disclosing information to or ingesting information from resource
   servers RqP does not want it to interact with in the given way.
   Again, flat authorization (the server can be authenticated) may be
   sufficient, or more fine-grained authorization may be required.  The
   client-side authorization also pertains to the level of protection
   required for the exchanges with the server (e.g., confidentiality).
   In the browser web, client-side authorization is often left to the
   human user; a constrained client may not have that available all the
   time but still needs to implement the wishes of the principal
   controlling it, the RqP.

   For the cases where an authorization solution is needed (all but
   unrestricted authorization), the enforcing party needs to be able to
   authenticate the party that is to be authorized.  Authentication is
   therefore required for messages that contain (or otherwise update)



Gerdes, et al.            Expires May 18, 2018                 [Page 15]


Internet-Draft                 ace-actors                  November 2017


   representations of an accessed item.  More precisely: The enforcing
   party needs to make sure that the receiver of a message containing a
   representation is authorized to receive it, both in the case of a
   client sending a representation to a server and vice versa.  In
   addition, it needs to ensure that the actual sender of a message
   containing a representation is indeed the one authorized to send this
   message, again for both the client-to-server and server-to-client
   case.  To achieve this, integrity protection of these messages is
   required: Authenticity of the message cannot be assured if it is
   possible for an attacker to modify it during transmission.

   In some cases, only one side (client or server side) requires the
   integrity and / or confidentiality of a resource value.  Principals
   may decide to omit authentication (unrestricted authorization), or
   use flat authorization (just employing an authentication mechanism).
   However, as indicated in Section 3, the security objectives of both
   sides must be considered, which can often only be achieved when the
   other side can be relied on to perform some security service.

5.  Actors and their Tasks

   This and the following section look at the resulting architecture
   from two different perspectives: This section provides a more
   detailed description of the various "actors" in the architecture, the
   logical functional entities performing the tasks required.  The
   following section then will focus on the protocols run between these
   functional entities.

   For the purposes of this document, an actor consists of a set of
   tasks and additionally has a security domain (client domain or server
   domain) and a level (constrained, principal, less-constrained).
   Tasks are assigned to actors according to their security domain and
   required level.

   Note that actors are a concept to understand the security
   requirements for constrained devices.  The architecture of an actual
   solution might differ as long as the security requirements that
   derive from the relationship between the identified actors are
   considered.  Several actors might share a single device or even be
   combined in a single piece of software.  Interfaces between actors
   may be realized as protocols or be internal to such a piece of
   software.

   A more detailed discussion of the tasks the actors have to perform in
   order to achieve specific security objectives is provided in
   [I-D.gerdes-ace-tasks].





Gerdes, et al.            Expires May 18, 2018                 [Page 16]


Internet-Draft                 ace-actors                  November 2017


5.1.  Constrained Level Actors

   As described in the problem statement (see Section 2), either C or RS
   or both of them may be located on a constrained node.  We therefore
   define that C and RS must be able to perform their tasks even if they
   are located on a constrained node.  Thus, C and RS are considered to
   be Constrained Level Actors.

   C performs the following tasks:

   o  Communicate in a secure way (provide for confidentiality and
      integrity of messages), including access requests.

   o  Validate that the RqP ("client-side") authorization information
      allows C to communicate with RS as a server for R (i.e., from C's
      point of view, RS is authorized as a server for the specific
      access to R).

   RS performs the following tasks:

   o  Communicate in a secure way (provide for confidentiality and
      integrity of messages), including responses to access requests.

   o  Validate that the RO ("server-side") authorization information
      allows RS to grant C access to the requested resource as requested
      (i.e., from RS' point of view, C is authorized as a client for the
      specific access to R).

   R is an item of interest such as a sensor or actuator value.  R is
   considered to be part of RS and not a separate actor.  The device on
   which RS is located might contain several resources controlled by
   different ROs.  For simplicity of exposition, these resources are
   described as if they had separate RS.

   As C and RS do not necessarily know each other they might belong to
   different security domains.

   (See Figure 8.)

           -------                            --------
           |  C  |  -- requests resource ---> |  RS  | Constrained Level
           -------  <-- provides resource---  --------


                    Figure 8: Constrained Level Actors






Gerdes, et al.            Expires May 18, 2018                 [Page 17]


Internet-Draft                 ace-actors                  November 2017


5.2.  Principal Level Actors

   Our objective is that C and RS are under control of principals in the
   physical world, the Requesting Party (RqP) and the Resource Owner
   (RO) respectively.  The principals decide about the security policies
   of their respective endpoints; each principal belongs to the same
   security domain as their endpoints.

   RqP is in charge of C, i.e. RqP specifies security policies for C,
   such as with whom C is allowed to communicate.  By definition, C and
   RqP belong to the same security domain.

   RqP must fulfill the following task:

   o  Configure for C authorization information for sources for R.

   RO is in charge of R and RS.  RO specifies authorization policies for
   R and decides with whom RS is allowed to communicate.  By definition,
   R, RS and RO belong to the same security domain.

   RO must fulfill the following task:

   o  Configure for RS authorization information for accessing R.

   (See Figure 2.)

5.3.  Less-Constrained Level Actors

   Constrained level actors can only fulfill a limited number of tasks
   and may not have network connectivity all the time.  To relieve them
   from having to manage keys for numerous endpoints and conducting
   computationally intensive tasks, another level of complexity for
   actors is introduced (and, thus, a stricter limit on their
   constrainedness).  An actor on the less-constrained level belongs to
   the same security domain as its respective constrained level actor.
   They also have the same principal.

   The Client Authorization Server (CAS) belongs to the same security
   domain as C and RqP.  CAS acts on behalf of RqP.  It assists C in
   authenticating RS and determining if RS is an authorized server for
   R.  CAS can do that because for C, CAS is the authority for claims
   about RS.

   CAS performs the following tasks:

   o  Validate on the client side that an entity has certain attributes.





Gerdes, et al.            Expires May 18, 2018                 [Page 18]


Internet-Draft                 ace-actors                  November 2017


   o  Obtain authorization information about an entity from C's
      principal (RqP) and provide it to C.

   o  Negotiate means for secure communication to communicate with C.

   The Authorization Server (AS) belongs to the same security domain as
   R, RS and RO.  AS acts on behalf of RO.  It supports RS by
   authenticating C and determining C's permissions on R.  AS can do
   that because for RS, AS is the authority for claims about C.

   AS performs the following tasks:

   o  Validate on the server side that an entity has certain attributes.

   o  Obtain authorization information about an entity from RS'
      principal (RO) and provide it to RS.

   o  Negotiate means for secure communication to communicate with RS.

6.  Kinds of Protocols

   Devices on the less-constrained level potentially are more powerful
   than constrained level devices in terms of processing power, memory,
   non-volatile storage.  This results in different characteristics for
   the protocols used on these levels.

6.1.  Constrained Level Protocols

   A protocol is considered to be on the constrained level if it is used
   between the actors C and RS which are considered to be constrained
   (see Section 5.1).  C and RS might not belong to the same security
   domain.  Therefore, constrained level protocols need to work between
   different security domains.

   Commonly used Internet protocols can not in every case be applied to
   constrained environments.  In some cases, tweaking and profiling is
   required.  In other cases it is beneficial to define new protocols
   which were designed with the special characteristics of constrained
   environments in mind.

   On the constrained level, protocols need to address the specific
   requirements of constrained environments.  Examples for protocols
   that consider these requirements is the transfer protocol CoAP
   (Constrained Application Protocol) [RFC7252] and the Datagram
   Transport Layer Security Protocol (DTLS) [RFC6347] which can be used
   for channel security.





Gerdes, et al.            Expires May 18, 2018                 [Page 19]


Internet-Draft                 ace-actors                  November 2017


   Constrained devices have only limited storage space and thus cannot
   store large numbers of keys.  This is especially important because
   constrained networks are expected to consist of thousands of nodes.
   Protocols on the constrained level should keep this limitation in
   mind.

6.1.1.  Cross Level Support Protocols

   We refer to protocols that operate between a constrained device and
   its corresponding less-constrained device as cross-level support
   protocols.  Protocols used between C and CAS or RS and AS are
   therefore support protocols.

   Support protocols must consider the limitations of their constrained
   endpoint and therefore belong to the constrained level protocols.

6.2.  Less-Constrained Level Protocols

   A protocol is considered to be on the less-constrained level if it is
   used between the actors CAS and AS.  CAS and AS might belong to
   different security domains.

   On the less-constrained level, HTTP [RFC7230] and Transport Layer
   Security (TLS) [RFC5246] can be used alongside or instead of CoAP and
   DTLS.  Moreover, existing security solutions for authentication and
   authorization such as the OAuth web authorization framework [RFC6749]
   and Kerberos [RFC4120] can likely be used without modifications and
   the less-constrained layer is assumed to impose no constraints that
   would inhibit the traditional deployment/use of, e.g., a Public Key
   Infrastructure (PKI).

7.  Elements of a Solution

   Without anticipating specific solutions, the following considerations
   may be helpful in discussing them.

7.1.  Authorization

   The core problem we are trying to solve is authorization.  The
   following problems related to authorization need to be addressed:

   o  AS needs to transfer authorization information to RS and CAS needs
      to transfer authorization information to C.

   o  The transferred authorization information needs to follow a
      defined format and encoding, which must be efficient for
      constrained devices, considering size of authorization information
      and parser complexity.



Gerdes, et al.            Expires May 18, 2018                 [Page 20]


Internet-Draft                 ace-actors                  November 2017


   o  C and RS need to be able to verify the authenticity of the
      authorization information they receive.  Here as well, there is a
      trade-off between processing complexity and deployment complexity.

   o  The RS needs to enforce the authorization decisions of the AS,
      while C needs to abide with the authorization decisions of the
      CAS.  The authorization information might require additional
      policy evaluation (such as matching against local access control
      lists, evaluating local conditions).  The required "policy
      evaluation" at the constrained actors needs to be adapted to the
      capabilities of the devices implementing them.

   o  Finally, as is indicated in the previous bullet, for a particular
      authorization decision there may be different kinds of
      authorization information needed, and these pieces of information
      may be transferred to C and RS at different times and in different
      ways prior to or during the client request.

7.2.  Authentication

   The following problems need to be addressed, when considering
   authentication:

   o  RS needs to authenticate AS, and C needs to authenticate CAS, to
      ensure that the authorization information and related data comes
      from the correct source.

   o  CAS and AS may need to authenticate each other, both to perform
      the required business logic and to ensure that CAS gets security
      information related to the resources from the right source.

   o  In some use cases RS needs to authenticate some property of C, in
      order to map it to the relevant authorization information.  In
      other applications, authentication and authorization of C may be
      implicit, for example by encrypting the resource representation
      the RS only providing access to those who possess the key to
      decrypt.

   o  C may need to authenticate RS, in order to ensure that it is
      interacting with the right resources.  Alternatively C may just
      verify the integrity of a received resource representation.

   o  CAS and AS need to authenticate their communication partner (C or
      RS), in order to ensure it serves the correct device.







Gerdes, et al.            Expires May 18, 2018                 [Page 21]


Internet-Draft                 ace-actors                  November 2017


7.3.  Communication Security

   There are different alternatives to provide communication security,
   and the problem here is to choose the optimal one for each scenario.
   We list the available alternatives:

   o  Session-based security at transport layer such as DTLS [RFC6347]
      offers security, including integrity and confidentiality
      protection, for the whole application layer exchange.  However,
      DTLS may not provide end-to-end security over multiple hops.
      Another problem with DTLS is the cost of the handshake protocol,
      which may be too expensive for constrained devices especially in
      terms of memory and power consumption for message transmissions.

   o  An alternative is object security at application layer, for
      instance using [I-D.ietf-core-object-security].  Secure objects
      can be stored or cached in network nodes and provide security for
      a more flexible communication model such as publish/subscribe
      (compare e.g.  CoRE Mirror Server [I-D.ietf-core-coap-pubsub]).  A
      problem with object security is that it can not provide
      confidentiality for the message headers.

   o  Hybrid solutions using both session-based and object security are
      also possible.  An example of a hybrid is where authorization
      information and cryptographic keys are provided by AS in the
      format of secure data objects, but where the resource access is
      protected by session-based security.

7.4.  Cryptographic Keys

   With respect to cryptographic keys, we see the following problems
   that need to be addressed:

   Symmetric vs Asymmetric Keys
      We need keys both for protection of resource access and for
      protection of transport of authentication and authorization
      information.  It may be necessary to support solutions that
      require the use of asymmetric keys as well as ones that get by
      with symmetric keys, in both cases.  There are classes of devices
      that can easily perform symmetric cryptography, but consume
      considerably more time/battery for asymmetric operations.  On the
      other hand asymmetric cryptography has benefits such as in terms
      of deployment.

   Key Establishment
      How are the corresponding cryptographic keys established?
      Considering Section 7.1 there must be a mapping between these keys
      and the authorization information, at least in the sense that AS



Gerdes, et al.            Expires May 18, 2018                 [Page 22]


Internet-Draft                 ace-actors                  November 2017


      must be able to specify a unique client identifier which RS can
      verify (using an associated key).  One of the use cases of
      [RFC7744] describes spontaneous change of access policies - such
      as giving a hitherto unknown client the right to temporarily
      unlock your house door.  In this case C is not previously known to
      RS and a key must be provisioned by AS.

   Revocation and Expiration
      How are keys replaced and how is a key that has been compromised
      revoked in a manner that reaches all affected parties, also
      keeping in mind scenarios with intermittent connectivity?

8.  Assumptions and Requirements

   In this section we list a set of candidate assumptions and
   requirements to make the problem description in the previous sections
   more concise and precise.  Note that many of these assumptions and
   requirements are targeting specific solutions and not the
   architecture itself.

8.1.  Architecture

   The architecture consists of at least the following types of nodes:

   o  RS hosting resources, and responding to access requests

   o  C requesting access to resources

   o  AS supporting the access request/response procedure by providing
      authorization information to RS

      *  AS may support this by aiding RS in authenticating C, or
         providing cryptographic keys or credentials to C and/or RS to
         secure the request/response procedure.

   o  CAS supporting the access request/response procedure by providing
      authorization information to C

      *  CAS may support this by aiding C in authenticating RS,
         forwarding information between AS and C (possibly ultimately
         for RS), or providing cryptographic keys or credentials to C
         and/or RS to secure the request/response procedure.

   o  The architecture allows for intermediary nodes between any pair of
      C, RS, AS, and CAS, such as forward or reverse proxies in the CoRE
      architecture.  (Solutions may or may not support all
      combinations.)




Gerdes, et al.            Expires May 18, 2018                 [Page 23]


Internet-Draft                 ace-actors                  November 2017


      *  The architecture does not make a choice between session based
         security and data object security.

8.2.  Constrained Devices

   o  C and/or RS may be constrained in terms of power, processing,
      communication bandwidth, memory and storage space, and moreover:

      *  unable to manage complex authorization policies

      *  unable to manage a large number of secure connections

      *  without user interface

      *  without constant network connectivity

      *  unable to precisely measure time

      *  required to save on wireless communication due to high power
         consumption

   o  CAS and AS are not assumed to be constrained devices.

   o  All devices under consideration can process symmetric cryptography
      without incurring an excessive performance penalty.

      *  We assume the use of a standardized symmetric key algorithm,
         such as AES.

      *  Except for the most constrained devices we assume the use of a
         standardized cryptographic hash function such as SHA-256 (which
         can be used with the HMAC construction for integrity
         protection).

   o  Public key cryptography requires additional resources (such as
      RAM, ROM, power, specialized hardware).

   o  A DTLS handshake involves significant computation, communication,
      and memory overheads in the context of constrained devices.

      *  The RAM requirements of DTLS handshakes with public key
         cryptography are prohibitive for certain constrained devices.

      *  Certificate-based DTLS handshakes require significant volumes
         of communication, RAM (message buffers) and computation.






Gerdes, et al.            Expires May 18, 2018                 [Page 24]


Internet-Draft                 ace-actors                  November 2017


   o  A solution will need to consider support for a simple scheme for
      expiring authentication and authorization information on devices
      which are unable to measure time (cf. Section 9.2).

8.3.  Authentication

   o  RS needs to authenticate AS to ensure that the authorization
      information and related data comes from the correct source.

   o  Similarly, C needs to authenticate CAS to ensure that the
      authorization information and related data comes from the correct
      source.

   o  Depending on use case and authorization requirements, C, RS, CAS,
      or AS may need to authenticate messages from each other.

8.4.  Server-side Authorization

   o  RS enforces authorization for access to a resource based on
      credentials presented by C, the requested resource, the REST
      method, and local context in RS at the time of the request, or on
      any subset of this information.

   o  The credentials presented by C may have been provided by CAS.

   o  The underlying authorization decision is taken either by AS or RS.

   o  The authorization decision is enforced by RS.

      *  RS needs to have authorization information in order to verify
         that C is allowed to access the resource as requested.

      *  RS needs to make sure that it provides resource access only to
         authorized clients.

   o  Apart from authorization for access to a resource, authorization
      may also be required for access to information about a resource
      (for instance, resource descriptions).

   o  The solution may need to be able to support the delegation of
      access rights.

8.5.  Client-side Authorization Information

   o  C enforces client-side authorization by protecting its requests to
      RS and by authenticating results from RS, making use of decisions
      and policies as well as keying material provided by CAS.




Gerdes, et al.            Expires May 18, 2018                 [Page 25]


Internet-Draft                 ace-actors                  November 2017


8.6.  Server-side Authorization Information

   o  Authorization information is transferred from AS to RS using
      Agent, Push or Pull mechanisms [RFC2904].

   o  RS needs to authenticate that the authorization information is
      coming from AS (integrity).

   o  The authorization information may also be encrypted end-to-end
      between AS and RS (confidentiality).

   o  The architecture supports the case where RS may not be able to
      communicate with AS at the time of the request from C.

   o  RS may store or cache authorization information.

   o  Authorization information may be pre-configured in RS.

   o  Authorization information stored or cached in RS needs to be
      possible to change.  The change of such information needs to be
      subject to authorization.

   o  Authorization policies stored on RS may be handled as a resource,
      i.e. information located at a particular URI, accessed with
      RESTful methods, and the access being subject to the same
      authorization mechanics.  AS may have special privileges when
      requesting access to the authorization policy resources on RS.

   o  There may be mechanisms for C to look up the AS which provides
      authorization information about a particular resource.

8.7.  Resource Access

   o  Resources are accessed in a RESTful manner using methods such as
      GET, PUT, POST, DELETE.

   o  By default, the resource request needs to be integrity protected
      and may be encrypted end-to-end from C to RS.  It needs to be
      possible for RS to detect a replayed request.

   o  By default, the response to a request needs to be integrity
      protected and may be encrypted end-to-end from RS to C.  It needs
      to be possible for C to detect a replayed response.

   o  RS needs to be able to verify that the request comes from an
      authorized client.





Gerdes, et al.            Expires May 18, 2018                 [Page 26]


Internet-Draft                 ace-actors                  November 2017


   o  C needs to be able to verify that the response to a request comes
      from the intended RS.

   o  There may be resources whose access need not be protected (e.g.
      for discovery of the responsible AS).

8.8.  Keys and Cipher Suites

   o  A constrained node and its authorization manager (i.e., RS and AS,
      and C and CAS) have established cryptographic keys.  For example,
      they share a secret key or each have the other's public key.

   o  The transfer of authorization information is protected with
      symmetric and/or asymmetric keys.

   o  The access request/response can be protected with symmetric and/or
      asymmetric keys.

   o  There must be a mechanism for RS to establish the necessary key(s)
      to verify and decrypt the request and to protect the response.

   o  There must be a mechanism for C to establish the necessary key(s)
      to protect the request and to verify and decrypt the response.

   o  There must be a mechanism for C to obtain the supported cipher
      suites of a RS.

8.9.  Network Considerations

   o  A solution will need to consider network overload due to avoidable
      communication of a constrained node with its authorization manager
      (C with CAS, RS with AS).

   o  A solution will need to consider network overload by compact
      authorization information representation.

   o  A solution may want to optimize the case where authorization
      information does not change often.

   o  A solution may consider support for an efficient mechanism for
      providing authorization information to multiple RSs, for example
      when multiple entities need to be configured or change state.

8.10.  Legacy Considerations

   o  A solution may consider interworking with existing infrastructure.





Gerdes, et al.            Expires May 18, 2018                 [Page 27]


Internet-Draft                 ace-actors                  November 2017


   o  A solution may consider supporting authorization of access to
      legacy devices.

9.  Security Considerations

   This document discusses authorization-related tasks for constrained
   environments and describes how these tasks can be mapped to actors in
   the architecture.

   The entire document is about security.  Security considerations
   applicable to authentication and authorization in RESTful
   environments are provided in e.g.  OAuth 2.0 [RFC6749].

   In this section we focus on specific security aspects related to
   authorization in constrained-node networks.  Section 11.6 of
   [RFC7252], "Constrained node considerations", discusses implications
   of specific constraints on the security mechanisms employed.  A wider
   view of security in constrained-node networks is provided in
   [I-D.irtf-t2trg-iot-seccons].

9.1.  Physical Attacks on Sensor and Actuator Networks

   The focus of this work is on constrained-node networks consisting of
   connected constrained devices such as sensors and actuators.  The
   main function of such devices is to interact with the physical world
   by gathering information or performing an action.  We now discuss
   attacks performed with physical access to such devices.

   The main threats to sensors and actuator networks are:

   o  Unauthorized access to data to and from sensors and actuators,
      including eavesdropping and manipulation of data.

   o  Denial-of-service making the sensor/actuator unable to perform its
      intended task correctly.

      A number of attacks can be made with physical access to a device
      including probing attacks, timing attacks, power attacks, etc.
      However, with physical access to a sensor or actuator device it is
      possible to directly perform attacks equivalent of eavesdropping,
      manipulating data or denial of service.  For example:

   o  Instead of eavesdropping the sensor data or attacking the
      authorization system to gain access to the data, the attacker
      could make its own measurements on the physical object.






Gerdes, et al.            Expires May 18, 2018                 [Page 28]


Internet-Draft                 ace-actors                  November 2017


   o  Instead of manipulating the sensor data the attacker could change
      the physical object which the sensor is measuring, thereby
      changing the payload data which is being sent.

   o  Instead of manipulating data for an actuator or attacking the
      authorization system, the attacker could perform an unauthorized
      action directly on the physical object.

   o  A denial-of-service attack could be performed physically on the
      object or device.

      All these attacks are possible by having physical access to the
      device, since the assets are related to the physical world.
      Moreover, this kind of attacks are in many cases straightforward
      (requires no special competence or tools, low cost given physical
      access, etc.)

      As a conclusion, if an attacker has full physical access to a
      sensor or actuator device, then much of the security functionality
      elaborated in this draft may not be effective to protect the asset
      during the physical attack.

      Since it does not make sense to design a solution for a situation
      that cannot be protected against we assume there is no need to
      protect assets the secrets or functioning of which are exposed
      during a physical attack.  In other words, either an attacker does
      not have physical access to the secrets or functioning of the
      sensor or actuator device, or if it has, the attack shall only
      have effect during the period of physical attack, and shall be
      limited in extent to the physical control the attacker exerts
      (e.g., must not affect the security of other devices.)

9.2.  Clocks and Time Measurements

   Some applications may require a device to be aware of the wall-clock
   time (e.g., a door lock that opens Monday to Friday at specific
   times, except for holidays).  Other applications only need to be able
   to measure short relative time (e.g., a door lock that keeps the door
   open for ten seconds after receiving a state change to open; such a
   door lock may be limited in its time-keeping accuracy and may not be
   able to keep time across power failures).

   In addition to application requirements of this kind, measuring time
   and keeping wall-clock time with certain accuracy is important to
   achieve certain security properties, for example to determine whether
   a public key certificate, access token, or some other assertion, is
   valid.




Gerdes, et al.            Expires May 18, 2018                 [Page 29]


Internet-Draft                 ace-actors                  November 2017


   Dynamic authorization in itself requires the ability to handle expiry
   or revocation of authorization decisions or to distinguish new
   authorization decisions from old.

   For certain categories of devices we can assume that there is an
   internal clock which is sufficiently accurate to handle the time
   measurement requirements.  If RS can connect directly to AS, this
   relationship can be used to update RS in terms of time, removing some
   uncertainty, as well as to directly provide revocation information,
   removing authorizations that are no longer desired.

   If RS continuously measures time but can't connect to AS or another
   trusted source of time, time drift may have to be accepted and it may
   be harder to manage revocation.  However, RS may still be able to
   handle short lived access rights within some margins, by measuring
   the time since arrival of authorization information or request.

   Some categories of devices in scope may be unable to measure time
   with any accuracy (e.g. because of sleep cycles).  This category of
   devices is not suitable for the use cases which require measuring
   validity of assertions and authorizations in terms of absolute time.

10.  IANA Considerations

   This document has no actions for IANA.

11.  Informative References

   [HUM14delegation]
              Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K.
              Wehrle, "Delegation-based Authentication and Authorization
              for the IP-based Internet of Things", 11th IEEE
              International Conference on Sensing, Communication, and
              Networking (SECON'14), June 30 - July 3, 2014.

   [I-D.gerdes-ace-tasks]
              Gerdes, S., "Authorization-Related Tasks in Constrained
              Environments", draft-gerdes-ace-tasks-00 (work in
              progress), September 2015.

   [I-D.hardjono-oauth-umacore]
              Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
              "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
              hardjono-oauth-umacore-14 (work in progress), January
              2016.






Gerdes, et al.            Expires May 18, 2018                 [Page 30]


Internet-Draft                 ace-actors                  November 2017


   [I-D.ietf-core-coap-pubsub]
              Koster, M., Keranen, A., and J. Jimenez, "Publish-
              Subscribe Broker for the Constrained Application Protocol
              (CoAP)", draft-ietf-core-coap-pubsub-02 (work in
              progress), July 2017.

   [I-D.ietf-core-object-security]
              Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", draft-ietf-core-object-security-06 (work in
              progress), October 2017.

   [I-D.irtf-t2trg-iot-seccons]
              Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
              the-Art and Challenges for the Internet of Things
              Security", draft-irtf-t2trg-iot-seccons-08 (work in
              progress), October 2017.

   [OSCAR]    Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A.,
              Damon, L., and R. Guizzetti, "OSCAR: Object Security
              Architecture for the Internet of Things", CoRR vol.
              abs/1404.7799, 2014.

   [REST]     Fielding, R. and R. Taylor, "Principled design of the
              modern Web architecture", ACM Trans. Inter. Tech. Vol.
              2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002.

   [RFC2904]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Framework", RFC 2904,
              DOI 10.17487/RFC2904, August 2000,
              <https://www.rfc-editor.org/info/rfc2904>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,
              <https://www.rfc-editor.org/info/rfc4120>.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
              <https://www.rfc-editor.org/info/rfc4949>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <https://www.rfc-editor.org/info/rfc5246>.





Gerdes, et al.            Expires May 18, 2018                 [Page 31]


Internet-Draft                 ace-actors                  November 2017


   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7744]  Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
              and S. Kumar, "Use Cases for Authentication and
              Authorization in Constrained Environments", RFC 7744,
              DOI 10.17487/RFC7744, January 2016,
              <https://www.rfc-editor.org/info/rfc7744>.

Acknowledgements

   The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
   Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
   Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
   and Erik Wahlstroem for contributing to the discussion, giving
   helpful input and commenting on previous forms of this draft.  The
   authors would also like to specifically acknowledge input provided by
   Hummen and others [HUM14delegation].  Robin Wilton provided extensive
   editorial comments that were the basis for significant improvements
   of the text.






Gerdes, et al.            Expires May 18, 2018                 [Page 32]


Internet-Draft                 ace-actors                  November 2017


Authors' Addresses

   Stefanie Gerdes
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63906
   Email: gerdes@tzi.org


   Ludwig Seitz
   RISE SICS
   Scheelevaegen 17
   Lund  223 70
   Sweden

   Email: ludwig.seitz@ri.se


   Goeran Selander
   Ericsson
   Faroegatan 6
   Kista  164 80
   Sweden

   Email: goran.selander@ericsson.com


   Carsten Bormann (editor)
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org













Gerdes, et al.            Expires May 18, 2018                 [Page 33]