draft-ietf-ace-actors-06.txt   draft-ietf-ace-actors-07.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational L. Seitz Intended status: Informational L. Seitz
Expires: May 18, 2018 RISE SICS Expires: April 25, 2019 RISE SICS
G. Selander G. Selander
Ericsson Ericsson AB
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
November 14, 2017 October 22, 2018
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-06 draft-ietf-ace-actors-07
Abstract Abstract
Constrained-node networks are networks where some nodes have severe Constrained-node networks are networks where some nodes have severe
constraints on code size, state memory, processing capabilities, user constraints on code size, state memory, processing capabilities, user
interface, power and communication bandwidth (RFC 7228). interface, power and communication bandwidth (RFC 7228).
This document provides terminology, and identifies the elements that This document provides terminology, and identifies the elements that
an architecture needs to address, providing a problem statement, for an architecture needs to address, providing a problem statement, for
authentication and authorization in these networks. authentication and authorization in these networks.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 18, 2018. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture and High-level Problem Statement . . . . . . . . 6 2. Architecture and High-level Problem Statement . . . . . . . . 6
2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6
2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 9 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 9
2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11 2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11
3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 13
3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13 3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13
4. Authentication and Authorization . . . . . . . . . . . . . . 14 4. Authentication and Authorization . . . . . . . . . . . . . . 14
5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16
5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 17 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 17
5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18
5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 20
6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20
6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20
7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 21
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 21
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 21 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 22
7.3. Communication Security . . . . . . . . . . . . . . . . . 22 7.3. Communication Security . . . . . . . . . . . . . . . . . 22
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 23
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 23 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 24
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 23 8.1. Constrained Devices . . . . . . . . . . . . . . . . . . . 24
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 24 8.2. Server-side Authorization . . . . . . . . . . . . . . . . 24
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 25 8.3. Client-side Authorization Information . . . . . . . . . . 25
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 25 8.4. Resource Access . . . . . . . . . . . . . . . . . . . . . 25
8.5. Client-side Authorization Information . . . . . . . . . . 25 8.5. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 25
8.6. Server-side Authorization Information . . . . . . . . . . 26 8.6. Network Considerations . . . . . . . . . . . . . . . . . 26
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27
8.9. Network Considerations . . . . . . . . . . . . . . . . . 27 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 27
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Informative References . . . . . . . . . . . . . . . . . . . 28
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
As described in [RFC7228], constrained nodes are small devices with As described in [RFC7228], constrained nodes are small devices with
limited abilities which in many cases are made to fulfill a specific limited abilities which in many cases are made to fulfill a specific
simple task. They may have limited hardware resources such as simple task. They may have limited hardware resources such as
processing power, memory, non-volatile storage and transmission processing power, memory, non-volatile storage and transmission
capacity and additionally in most cases do not have user interfaces capacity and additionally in most cases do not have user interfaces
and displays. Due to these constraints, commonly used security and displays. Due to these constraints, commonly used security
protocols are not always easily applicable, or may give rise to protocols are not always easily applicable, or may give rise to
skipping to change at page 5, line 27 skipping to change at page 5, line 25
Resource Server (RS): An entity which hosts and represents a Resource Server (RS): An entity which hosts and represents a
Resource. (Used here to discuss the server that provides a Resource. (Used here to discuss the server that provides a
resource that is the end, not the means, of the authenticated resource that is the end, not the means, of the authenticated
authorization process - i.e., not CAS or AS.) authorization process - i.e., not CAS or AS.)
Client (C): An entity which attempts to access a resource on a RS. 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, (Used to discuss the client whose access to a resource is the end,
not the means, of the authenticated authorization process.) not the means, of the authenticated authorization process.)
Principal: (Used in its English sense here, and specifically as:) An Overseeing principal: (Used in its English sense here, and
individual that is either RqP or RO or both. specifically as:) An individual that is either RqP or RO or both.
Resource Owner (RO): The principal that is in charge of the resource Resource Owner (RO): The overseeing principal that is in charge of
and controls its access permissions. the resource and controls its access permissions.
Requesting Party (RqP): The principal that is in charge of the Requesting Party (RqP): The overseeing principal that is in charge
Client and controls the requests a Client makes and its acceptance of the Client and controls the requests a Client makes and its
of responses. acceptance of responses.
Authorization Server (AS): An entity that prepares and endorses Authorization Server (AS): An entity that prepares and endorses
authentication and authorization data for a Resource Server. authentication and authorization data for a Resource Server.
Client Authorization Server (CAS): An entity that prepares and Client Authorization Server (CAS): An entity that prepares and
endorses authentication and authorization data for a Client. endorses authentication and authorization data for a Client.
Authorization Manager: An entity that prepares and endorses Authorization Manager: An entity that prepares and endorses
authentication and authorization data for a constrained node. authentication and authorization data for a constrained node.
Used in constructions such as "a constrained node's authorization Used in constructions such as "a constrained node's authorization
skipping to change at page 7, line 6 skipping to change at page 7, line 6
-------------- -------------- -------------- --------------
| ------- | | ------- | | ------- | | ------- |
| | C | ------ requests resource -----> | RS | | | | C | ------ requests resource -----> | RS | |
| ------- <----- provides resource ------ ------- | | ------- <----- provides resource ------ ------- |
| Endpoint | | Endpoint | | Endpoint | | Endpoint |
-------------- -------------- -------------- --------------
Figure 1: Constrained Level Figure 1: Constrained Level
The authorization decisions at the endpoints are made on behalf of The authorization decisions at the endpoints are made on behalf of
the principals that control the endpoints. To reuse OAuth and UMA the overseeing principals that control the endpoints. To reuse OAuth
terminology, the present document calls the principal that is and UMA terminology, the present document calls the overseeing
controlling C the Requesting Party (RqP), and calls the principal principal that is controlling C the Requesting Party (RqP), and calls
that is controlling RS the Resource Owner (RO). Each principal makes the overseeing principal that is controlling RS the Resource Owner
authorization decisions (possibly encapsulating them into security (RO). Each overseeing principal makes authorization decisions
policies) which are then enforced by the endpoint it controls. (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 The specific security objectives will vary, but for any specific
version of this scenario will include one or more of: version of this scenario will include one or more of:
o Objectives of type 1: No entity not authorized by the RO has o Objectives of type 1: No entity not authorized by the RO has
access to (or otherwise gains knowledge of) R. access to (or otherwise gains knowledge of) R.
o Objectives of type 2: C is exchanging information with (sending a o Objectives of type 2: C is exchanging information with (sending a
request to, accepting a response from) a resource only where it request to, accepting a response from) a resource only where it
can ascertain that RqP has authorized the exchange with R. can ascertain that RqP has authorized the exchange with R.
skipping to change at page 7, line 44 skipping to change at page 7, line 45
in charge of in charge of in charge of in charge of
| | | |
V V V V
------- ------- ------- -------
| C | -- requests resource --> | RS | Constrained Level | C | -- requests resource --> | RS | Constrained Level
------- <-- provides resource-- ------- ------- <-- provides resource-- -------
Figure 2: Constrained Level and Principal Level Figure 2: Constrained Level and Principal Level
The use cases defined in [RFC7744] demonstrate that constrained The use cases defined in [RFC7744] demonstrate that constrained
devices are often used for scenarios where their principals are not devices are often used for scenarios where their overseeing
present at the time of the communication, are not able to communicate principals are not present at the time of the communication, are not
directly with the device because of a lack of user interfaces or able to communicate directly with the device because of a lack of
displays, or may prefer the device to communicate autonomously. user interfaces or displays, or may prefer the device to communicate
autonomously.
Moreover, constrained endpoints may need support with tasks requiring Moreover, constrained endpoints may need support with tasks requiring
heavy processing, large memory or storage, or interfacing to humans, heavy processing, large memory or storage, or interfacing to humans,
such as management of security policies defined by a principal. The such as management of security policies defined by an overseeing
principal, in turn, requires some agent maintaining the policies principal. The principal, in turn, requires some agent maintaining
governing how its endpoints will interact. the policies governing how its endpoints will interact.
For these reasons, another level of nodes is introduced in the For these reasons, another level of nodes is introduced in the
architecture, the less-constrained level (illustrated below in architecture, the less-constrained level (illustrated below in
Figure 3). Using OAuth terminology, AS acts on behalf of the RO to Figure 3). Using OAuth terminology, AS acts on behalf of the RO to
control and support the RS in handling access requests, employing a control and support the RS in handling access requests, employing a
pre-existing security relationship with RS. We complement this with pre-existing security relationship with RS. We complement this with
CAS acting on behalf of RqP to control and support the C in making CAS acting on behalf of RqP to control and support the C in making
resource requests and acting on the responses received, employing a resource requests and acting on the responses received, employing a
pre-existing security relationship with C. To further relieve the pre-existing security relationship with C. To further relieve the
constrained level, authorization (and related authentication) constrained level, authorization (and related authentication)
mechanisms may be employed between CAS and AS (Section 6.2). (Again, mechanisms may be employed between CAS and AS (Section 6.2). (Again,
both CAS and AS are conceptual entities controlled by their both CAS and AS are conceptual entities controlled by their
respective principals. Many of these entities, often acting for respective overseeing principals. Many of these entities, often
different principals, can be combined into a single server acting for different overseeing principals, can be combined into a
implementation; this of course requires proper segregation of the single server implementation; this of course requires proper
control information provided by each principal.) segregation of the control information provided by each overseeing
principal.)
------- ------- ------- -------
| RqP | | RO | Principal Level | RqP | | RO | Principal Level
------- ------- ------- -------
| | | |
controls controls controls controls
| | | |
V V V V
-------- ------- -------- -------
| CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level
skipping to change at page 10, line 27 skipping to change at page 10, line 27
and authorization ___/ and authorization ___/
support ___/ request resource / provides resource support ___/ request resource / provides resource
| ___/ | ___/
V ___/ V ___/
------- / ------- /
| C | <- | C | <-
------- -------
Figure 5: Combined AS and RS Figure 5: Combined AS and RS
If C and RS have the same principal, CAS and AS can be combined. If C and RS have the same overseeing principal, CAS and AS can be
combined.
------------ ------------
| RqP = RO | Principal Level | RqP = RO | Principal Level
------------ ------------
| |
in charge of in charge of
| |
V V
-------------- --------------
| CAS + AS | Less-Constrained Level | CAS + AS | Less-Constrained Level
skipping to change at page 12, line 11 skipping to change at page 12, line 33
o Any necessary keys/credentials for protecting the interaction o Any necessary keys/credentials for protecting the interaction
between the potentially constrained nodes will need to be between the potentially constrained nodes will need to be
established and maintained as part of a solution. established and maintained as part of a solution.
In terms of the elements of the architecture laid out above, this In terms of the elements of the architecture laid out above, this
document's problem statement for authorization in constrained document's problem statement for authorization in constrained
environments can then be summarized as follows: environments can then be summarized as follows:
o The interaction between potentially constrained endpoints is o The interaction between potentially constrained endpoints is
controlled by control information provided by less-constrained controlled by control information provided by less-constrained
nodes on behalf of the principals of the endpoints. nodes on behalf of the overseeing principals of the endpoints.
o The interaction between the endpoints needs to be secured, as well o The interaction between the endpoints needs to be secured, as well
as the establishment of the necessary keys for securing the as the establishment of the necessary keys for securing the
interaction, potentially end-to-end through intermediary nodes. interaction, potentially end-to-end through intermediary nodes.
o The mechanism for transferring control information needs to be o The mechanism for transferring control information needs to be
secured, potentially end-to-end through intermediary nodes. Pre- secured, potentially end-to-end through intermediary nodes. Pre-
established keying material may need to be employed for established keying material may need to be employed for
establishing the keys used to protect these information flows. establishing the keys used to protect these information flows.
skipping to change at page 14, line 37 skipping to change at page 15, line 15
authorization. authorization.
Where used for authorization, the set of authenticated attributes Where used for authorization, the set of authenticated attributes
must be meaningful for this purpose, i.e., authorization decisions must be meaningful for this purpose, i.e., authorization decisions
must be possible based on these attributes. If the authorization must be possible based on these attributes. If the authorization
policy assigns permissions to an individual entity, the set of policy assigns permissions to an individual entity, the set of
authenticated attributes must be suitable to uniquely identify this authenticated attributes must be suitable to uniquely identify this
entity. entity.
In scenarios where devices are communicating autonomously there is In scenarios where devices are communicating autonomously there is
often less need to uniquely identify an individual device: For a often less need to uniquely identify an individual device: For an
principal, the fact that a device belongs to a certain company or overseeing principal, the fact that a device belongs to a certain
that it has a specific type (such as a light bulb) or location may be company or that it has a specific type (such as a light bulb) or
more important than that it has a unique identifier. 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 Overseeing principals (RqP and RO) need to decide about the required
granularity for the authorization. For example, we distinguish level of granularity for the authorization. For example, we
device authorization from owner authorization, and flat authorization distinguish device authorization from owner authorization, and binary
from unrestricted authorization. In the first case different access authorization from unrestricted authorization. In the first case
permissions are granted to individual devices while in the second different access permissions are granted to individual devices while
case individual owners are authorized. If flat authorization is in the second case individual owners are authorized. If binary
used, all authenticated entities are implicitly authorized and have authorization is used, all authenticated entities are implicitly
the same access permissions. Unrestricted authorization for an item authorized and have the same access permissions. Unrestricted
of interest means that no authorization mechanism is used for authorization for an item of interest means that no authorization
accessing this resource (not even by authentication) and all entities mechanism is used for accessing this resource (not even by
are able to access the item as they see fit (note that an authentication) and all entities are able to access the item as they
authorization mechanism may still be used to arrive at the decision see fit (note that an authorization mechanism may still be used to
to employ unrestricted authorization). arrive at the decision to employ unrestricted authorization).
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Authorization | Authorization is contingent on: | | Authorization | Authorization is contingent on: |
| granularity | | | granularity | |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| device | authentication of specific device | | device | authentication of specific device |
| | | | | |
| owner | (authenticated) authorization by owner | | owner | (authenticated) authorization by owner |
| | | | | |
| flat | (any) authentication | | binary | (any) authentication |
| | | | | |
| unrestricted | (unrestricted access; access always authorized) | | unrestricted | (unrestricted access; access always authorized) |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 1: Some granularity levels for authorization Table 1: Some granularity levels for authorization
More fine-grained authorization does not necessarily provide more More fine-grained authorization does not necessarily provide more
security but can be more flexible. Principals need to consider that security but can be more flexible. Overseeing principals need to
an entity should only be granted the permissions it really needs consider that an entity should only be granted the permissions it
(principle of least privilege), to ensure the confidentiality and really needs (principle of least privilege), to ensure the
integrity of resources. confidentiality and integrity of resources.
Client-side authorization solutions aim at protecting the client from Client-side authorization solutions aim at protecting the client from
disclosing information to or ingesting information from resource disclosing information to or ingesting information from resource
servers RqP does not want it to interact with in the given way. servers RqP does not want it to interact with in the given way.
Again, flat authorization (the server can be authenticated) may be Again, binary authorization (the server can be authenticated) may be
sufficient, or more fine-grained authorization may be required. The sufficient, or more fine-grained authorization may be required. The
client-side authorization also pertains to the level of protection client-side authorization also pertains to the level of protection
required for the exchanges with the server (e.g., confidentiality). required for the exchanges with the server (e.g., confidentiality).
In the browser web, client-side authorization is often left to the In the browser web, client-side authorization is often left to the
human user; a constrained client may not have that available all the human user that directly controls the client; a constrained client
time but still needs to implement the wishes of the principal may not have that available all the time but still needs to implement
controlling it, the RqP. the wishes of the overseeing principal controlling it, the RqP.
For the cases where an authorization solution is needed (all but For the cases where an authorization solution is needed (all but
unrestricted authorization), the enforcing party needs to be able to unrestricted authorization), the enforcing party needs to be able to
authenticate the party that is to be authorized. Authentication is authenticate the party that is to be authorized. Authentication is
therefore required for messages that contain (or otherwise update) therefore required for messages that contain (or otherwise update)
representations of an accessed item. More precisely: The enforcing representations of an accessed item. More precisely: The enforcing
party needs to make sure that the receiver of a message containing a 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 representation is authorized to receive it, both in the case of a
client sending a representation to a server and vice versa. In client sending a representation to a server and vice versa. In
addition, it needs to ensure that the actual sender of a message addition, it needs to ensure that the actual sender of a message
containing a representation is indeed the one authorized to send this containing a representation is indeed the one authorized to send this
message, again for both the client-to-server and server-to-client message, again for both the client-to-server and server-to-client
case. To achieve this, integrity protection of these messages is case. To achieve this, integrity protection of these messages is
required: Authenticity of the message cannot be assured if it is required: Authenticity of the message cannot be assured if it is
possible for an attacker to modify it during transmission. possible for an attacker to modify it during transmission.
In some cases, only one side (client or server side) requires the In some cases, only one side (client or server side) requires the
integrity and / or confidentiality of a resource value. Principals integrity and / or confidentiality of a resource value. Overseeing
may decide to omit authentication (unrestricted authorization), or principals may decide to omit authentication (unrestricted
use flat authorization (just employing an authentication mechanism). authorization), or use binary authorization (just employing an
However, as indicated in Section 3, the security objectives of both authentication mechanism). However, as indicated in Section 3, the
sides must be considered, which can often only be achieved when the security objectives of both sides must be considered, which can often
other side can be relied on to perform some security service. only be achieved when the other side can be relied on to perform some
security service.
5. Actors and their Tasks 5. Actors and their Tasks
This and the following section look at the resulting architecture This and the following section look at the resulting architecture
from two different perspectives: This section provides a more from two different perspectives: This section provides a more
detailed description of the various "actors" in the architecture, the detailed description of the various "actors" in the architecture, the
logical functional entities performing the tasks required. The logical functional entities performing the tasks required. The
following section then will focus on the protocols run between these following section then will focus on the protocols run between these
functional entities. functional entities.
skipping to change at page 16, line 47 skipping to change at page 17, line 20
Note that actors are a concept to understand the security Note that actors are a concept to understand the security
requirements for constrained devices. The architecture of an actual requirements for constrained devices. The architecture of an actual
solution might differ as long as the security requirements that solution might differ as long as the security requirements that
derive from the relationship between the identified actors are derive from the relationship between the identified actors are
considered. Several actors might share a single device or even be considered. Several actors might share a single device or even be
combined in a single piece of software. Interfaces between actors combined in a single piece of software. Interfaces between actors
may be realized as protocols or be internal to such a piece of may be realized as protocols or be internal to such a piece of
software. 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].
5.1. Constrained Level Actors 5.1. Constrained Level Actors
As described in the problem statement (see Section 2), either C or RS 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 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 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 are located on a constrained node. Thus, C and RS are considered to
be Constrained Level Actors. be Constrained Level Actors.
C performs the following tasks: C performs the following tasks:
skipping to change at page 18, line 7 skipping to change at page 18, line 18
(See Figure 8.) (See Figure 8.)
------- -------- ------- --------
| C | -- requests resource ---> | RS | Constrained Level | C | -- requests resource ---> | RS | Constrained Level
------- <-- provides resource--- -------- ------- <-- provides resource--- --------
Figure 8: Constrained Level Actors Figure 8: Constrained Level Actors
5.2. Principal Level Actors 5.2. Principal Level Actors
Our objective is that C and RS are under control of principals in the Our objective is that C and RS are under control of overseeing
physical world, the Requesting Party (RqP) and the Resource Owner principals in the physical world, the Requesting Party (RqP) and the
(RO) respectively. The principals decide about the security policies Resource Owner (RO) respectively. The overseeing principals decide
of their respective endpoints; each principal belongs to the same about the security policies of their respective endpoints; each
security domain as their endpoints. overseeing principal belongs to the same security domain as their
endpoints.
RqP is in charge of C, i.e. RqP specifies security policies for C, 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 such as with whom C is allowed to communicate. By definition, C and
RqP belong to the same security domain. RqP belong to the same security domain.
RqP must fulfill the following task: RqP must fulfill the following task:
o Configure for C authorization information for sources for R. o Configure for C authorization information for sources for R.
RO is in charge of R and RS. RO specifies authorization policies for RO is in charge of R and RS. RO specifies authorization policies for
skipping to change at page 18, line 40 skipping to change at page 19, line 5
5.3. Less-Constrained Level Actors 5.3. Less-Constrained Level Actors
Constrained level actors can only fulfill a limited number of tasks Constrained level actors can only fulfill a limited number of tasks
and may not have network connectivity all the time. To relieve them and may not have network connectivity all the time. To relieve them
from having to manage keys for numerous endpoints and conducting from having to manage keys for numerous endpoints and conducting
computationally intensive tasks, another level of complexity for computationally intensive tasks, another level of complexity for
actors is introduced (and, thus, a stricter limit on their actors is introduced (and, thus, a stricter limit on their
constrainedness). An actor on the less-constrained level belongs to constrainedness). An actor on the less-constrained level belongs to
the same security domain as its respective constrained level actor. the same security domain as its respective constrained level actor.
They also have the same principal. They also have the same overseeing principal.
The Client Authorization Server (CAS) belongs to the same security 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 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 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 R. CAS can do that because for C, CAS is the authority for claims
about RS. about RS.
CAS performs the following tasks: CAS performs the following tasks:
o Validate on the client side that an entity has certain attributes. o Vouch for the attributes of its clients.
o Obtain authorization information about an entity from C's o Ascertain that C's overseeing principal (RqP) authorized AS to
vouch for RS and provide keying material for it.
o Provide revocation information concerning its clients (optional).
o Obtain authorization information about RS from C's overseeing
principal (RqP) and provide it to C. principal (RqP) and provide it to C.
o Negotiate means for secure communication to communicate with C. o Negotiate means for secure communication to communicate with C.
The Authorization Server (AS) belongs to the same security domain as 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 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 authenticating C and determining C's permissions on R. AS can do
that because for RS, AS is the authority for claims about C. that because for RS, AS is the authority for claims about C.
AS performs the following tasks: AS performs the following tasks:
o Validate on the server side that an entity has certain attributes. o Vouch for the attributes of its resource servers.
o Obtain authorization information about an entity from RS' o Ascertain that RS's overseeing principal (RO) authorized CAS to
vouch for C and provide keying material for it.
o Provide revocation information concerning its servers (optional).
o Obtain authorization information about C from RS' overseeing
principal (RO) and provide it to RS. principal (RO) and provide it to RS.
o Negotiate means for secure communication to communicate with RS. o Negotiate means for secure communication to communicate with RS.
6. Kinds of Protocols 6. Kinds of Protocols
Devices on the less-constrained level potentially are more powerful Devices on the less-constrained level potentially are more powerful
than constrained level devices in terms of processing power, memory, than constrained level devices in terms of processing power, memory,
non-volatile storage. This results in different characteristics for non-volatile storage. This results in different characteristics for
the protocols used on these levels. the protocols used on these levels.
skipping to change at page 20, line 28 skipping to change at page 20, line 49
Support protocols must consider the limitations of their constrained Support protocols must consider the limitations of their constrained
endpoint and therefore belong to the constrained level protocols. endpoint and therefore belong to the constrained level protocols.
6.2. Less-Constrained Level Protocols 6.2. Less-Constrained Level Protocols
A protocol is considered to be on the less-constrained level if it is 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 used between the actors CAS and AS. CAS and AS might belong to
different security domains. different security domains.
On the less-constrained level, HTTP [RFC7230] and Transport Layer On the less-constrained level, HTTP [RFC7230] and Transport Layer
Security (TLS) [RFC5246] can be used alongside or instead of CoAP and Security (TLS) [RFC8246] can be used alongside or instead of CoAP and
DTLS. Moreover, existing security solutions for authentication and DTLS. Moreover, existing security solutions for authentication and
authorization such as the OAuth web authorization framework [RFC6749] authorization such as the OAuth web authorization framework [RFC6749]
and Kerberos [RFC4120] can likely be used without modifications and and Kerberos [RFC4120] can likely be used without modifications and
the less-constrained layer is assumed to impose no constraints that the less-constrained layer is assumed to impose no constraints that
would inhibit the traditional deployment/use of, e.g., a Public Key would inhibit the traditional deployment/use of, e.g., a Public Key
Infrastructure (PKI). Infrastructure (PKI).
7. Elements of a Solution 7. Elements of a Solution
Without anticipating specific solutions, the following considerations Without anticipating specific solutions, the following considerations
skipping to change at page 21, line 6 skipping to change at page 21, line 27
o AS needs to transfer authorization information to RS and CAS needs o AS needs to transfer authorization information to RS and CAS needs
to transfer authorization information to C. to transfer authorization information to C.
o The transferred authorization information needs to follow a o The transferred authorization information needs to follow a
defined format and encoding, which must be efficient for defined format and encoding, which must be efficient for
constrained devices, considering size of authorization information constrained devices, considering size of authorization information
and parser complexity. and parser complexity.
o C and RS need to be able to verify the authenticity of the o C and RS need to be able to verify the authenticity of the
authorization information they receive. Here as well, there is a authorization information they receive. C must ascertain that the
trade-off between processing complexity and deployment complexity. authorization information stems from a CAS that was authorized by
RqP, RS must validate that the authorization information stems
from an AS that was authorized by RO.
o Some applications may require the confidentiality of authorization
information. It then needs to be encrypted between CAS and C and
AS and RS, respectively.
o C and RS must be able to check the freshness of the authorization
information and determine for how long it is supposed to be valid.
o The RS needs to enforce the authorization decisions of the AS, o The RS needs to enforce the authorization decisions of the AS,
while C needs to abide with the authorization decisions of the while C needs to abide with the authorization decisions of the
CAS. The authorization information might require additional CAS. The authorization information might require additional
policy evaluation (such as matching against local access control policy evaluation (such as matching against local access control
lists, evaluating local conditions). The required "policy lists, evaluating local conditions). The required "policy
evaluation" at the constrained actors needs to be adapted to the evaluation" at the constrained actors needs to be adapted to the
capabilities of the devices implementing them. capabilities of the devices implementing them.
o Finally, as is indicated in the previous bullet, for a particular o Finally, as is indicated in the previous bullet, for a particular
authorization decision there may be different kinds of authorization decision there may be different kinds of
authorization information needed, and these pieces of information authorization information needed, and these pieces of information
may be transferred to C and RS at different times and in different may be transferred to C and RS at different times and in different
ways prior to or during the client request. ways prior to or during the client request.
7.2. Authentication 7.2. Authentication
The following problems need to be addressed, when considering The following problems need to be addressed, when considering
authentication: authentication:
o RS needs to authenticate AS, and C needs to authenticate CAS, to o RS needs to authenticate AS in the sense that it must be certain
ensure that the authorization information and related data comes that it communicates with an AS that was authorized by RO, C needs
from the correct source. to authenticate CAS in the sense that it must be certain that it
communicates with a CAS that was authorized by RqP, to ensure that
the authorization information and related data comes from the
correct source.
o C must securely have obtained keying material to communicate with
its CAS that is up to date and that is updated if necessary. RS
must securely have obtained keying material to communicate with AS
that is up to date and that is updated if necessary.
o CAS and AS may need to authenticate each other, both to perform o CAS and AS may need to authenticate each other, both to perform
the required business logic and to ensure that CAS gets security the required business logic and to ensure that CAS gets security
information related to the resources from the right source. information related to the resources from the right source.
o In some use cases RS needs to authenticate some property of C, in o In some use cases RS needs to authenticate some property of C, in
order to map it to the relevant authorization information. In order to map it to the relevant authorization information.
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 o C may need to authenticate RS, in order to ensure that it is
interacting with the right resources. Alternatively C may just interacting with the right resources.
verify the integrity of a received resource representation.
o CAS and AS need to authenticate their communication partner (C or o CAS and AS need to authenticate their communication partner (C or
RS), in order to ensure it serves the correct device. RS), in order to ensure it serves the correct device. If C and AS
vouch for keying material or certain attributes of their
respective constrained devices, they must ascertain that the
devices actually currently have this keying material or these
attributes.
7.3. Communication Security 7.3. Communication Security
There are different alternatives to provide communication security, There are different alternatives to provide communication security,
and the problem here is to choose the optimal one for each scenario. and the problem here is to choose the optimal one for each scenario.
We list the available alternatives: We list the available alternatives:
o Session-based security at transport layer such as DTLS [RFC6347] o Session-based security at transport layer such as DTLS [RFC6347]
offers security, including integrity and confidentiality offers security, including integrity and confidentiality
protection, for the whole application layer exchange. However, protection, for the whole application layer exchange. However,
skipping to change at page 23, line 24 skipping to change at page 24, line 13
keeping in mind scenarios with intermittent connectivity? keeping in mind scenarios with intermittent connectivity?
8. Assumptions and Requirements 8. Assumptions and Requirements
In this section we list a set of candidate assumptions and In this section we list a set of candidate assumptions and
requirements to make the problem description in the previous sections requirements to make the problem description in the previous sections
more concise and precise. Note that many of these assumptions and more concise and precise. Note that many of these assumptions and
requirements are targeting specific solutions and not the requirements are targeting specific solutions and not the
architecture itself. architecture itself.
8.1. Architecture 8.1. Constrained Devices
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.)
* 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, o C and/or RS may be constrained in terms of power, processing,
communication bandwidth, memory and storage space, and moreover: communication bandwidth, memory and storage space, and moreover:
* unable to manage complex authorization policies * unable to manage complex authorization policies
* unable to manage a large number of secure connections * unable to manage a large number of secure connections
* without user interface * without user interface
skipping to change at page 24, line 30 skipping to change at page 24, line 36
* unable to precisely measure time * unable to precisely measure time
* required to save on wireless communication due to high power * required to save on wireless communication due to high power
consumption consumption
o CAS and AS are not assumed to be constrained devices. o CAS and AS are not assumed to be constrained devices.
o All devices under consideration can process symmetric cryptography o All devices under consideration can process symmetric cryptography
without incurring an excessive performance penalty. 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 o Public key cryptography requires additional resources (such as
RAM, ROM, power, specialized hardware). 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.
o A solution will need to consider support for a simple scheme for o A solution will need to consider support for a simple scheme for
expiring authentication and authorization information on devices expiring authentication and authorization information on devices
which are unable to measure time (cf. Section 9.2). which are unable to measure time (cf. Section 9.2).
8.3. Authentication 8.2. Server-side Authorization
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 o RS enforces authorization for access to a resource based on
credentials presented by C, the requested resource, the REST credentials presented by C, the requested resource, the REST
method, and local context in RS at the time of the request, or on method, and local context in RS at the time of the request, or on
any subset of this information. 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. o The authorization decision is enforced by RS.
* RS needs to have authorization information in order to verify * RS needs to have authorization information in order to verify
that C is allowed to access the resource as requested. that C is allowed to access the resource as requested.
* RS needs to make sure that it provides resource access only to * RS needs to make sure that it provides resource access only to
authorized clients. authorized clients.
o Apart from authorization for access to a resource, authorization o Apart from authorization for access to a resource, authorization
may also be required for access to information about a resource may also be required for access to information about a resource
(for instance, resource descriptions). (for instance, resource descriptions).
o The solution may need to be able to support the delegation of 8.3. Client-side Authorization Information
access rights.
8.5. Client-side Authorization Information
o C enforces client-side authorization by protecting its requests to o C enforces client-side authorization by protecting its requests to
RS and by authenticating results from RS, making use of decisions RS and by authenticating results from RS, making use of decisions
and policies as well as keying material provided by CAS. and policies as well as keying material provided by CAS.
8.6. Server-side Authorization Information 8.4. Resource Access
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 o Resources are accessed in a RESTful manner using methods such as
GET, PUT, POST, DELETE. GET, PUT, POST, DELETE.
o By default, the resource request needs to be integrity protected 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 and may be encrypted end-to-end from C to RS. It needs to be
possible for RS to detect a replayed request. possible for RS to detect a replayed request.
o By default, the response to a request needs to be integrity 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 protected and may be encrypted end-to-end from RS to C. It needs
skipping to change at page 27, line 11 skipping to change at page 25, line 43
o RS needs to be able to verify that the request comes from an o RS needs to be able to verify that the request comes from an
authorized client. authorized client.
o C needs to be able to verify that the response to a request comes o C needs to be able to verify that the response to a request comes
from the intended RS. from the intended RS.
o There may be resources whose access need not be protected (e.g. o There may be resources whose access need not be protected (e.g.
for discovery of the responsible AS). for discovery of the responsible AS).
8.8. Keys and Cipher Suites 8.5. Keys and Cipher Suites
o A constrained node and its authorization manager (i.e., RS and AS, o A constrained node and its authorization manager (i.e., RS and AS,
and C and CAS) have established cryptographic keys. For example, and C and CAS) have established cryptographic keys. For example,
they share a secret key or each have the other's public key. they share a secret key or each have the other's public key.
o The transfer of authorization information is protected with o The transfer of authorization information is protected with
symmetric and/or asymmetric keys. symmetric and/or asymmetric keys.
o The access request/response can be protected with symmetric and/or o The access request/response is protected with symmetric and/or
asymmetric keys. asymmetric keys.
o There must be a mechanism for RS to establish the necessary key(s) 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. 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) 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. to protect the request and to verify and decrypt the response.
o There must be a mechanism for C to obtain the supported cipher o There must be a mechanism for C to obtain the supported cipher
suites of a RS. suites of a RS.
8.9. Network Considerations 8.6. Network Considerations
o A solution will need to consider network overload due to avoidable o A solution will need to consider network overload due to avoidable
communication of a constrained node with its authorization manager communication of a constrained node with its authorization manager
(C with CAS, RS with AS). (C with CAS, RS with AS).
o A solution will need to consider network overload by compact o A solution will need to consider network overload by compact
authorization information representation. authorization information representation.
o A solution may want to optimize the case where authorization o A solution may want to optimize the case where authorization
information does not change often. information does not change often.
o A solution should combine the mechanisms for providing
authentication and authorization information to the client and RS
where possible.
o A solution may consider support for an efficient mechanism for o A solution may consider support for an efficient mechanism for
providing authorization information to multiple RSs, for example providing authorization information to multiple RSs, for example
when multiple entities need to be configured or change state. when multiple entities need to be configured or change state.
8.10. Legacy Considerations
o A solution may consider interworking with existing infrastructure.
o A solution may consider supporting authorization of access to
legacy devices.
9. Security Considerations 9. Security Considerations
This document discusses authorization-related tasks for constrained This document discusses authorization-related tasks for constrained
environments and describes how these tasks can be mapped to actors in environments and describes how these tasks can be mapped to actors in
the architecture. 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 In this section we focus on specific security aspects related to
authorization in constrained-node networks. Section 11.6 of authorization in constrained-node networks. Section 11.6 of
[RFC7252], "Constrained node considerations", discusses implications [RFC7252], "Constrained node considerations", discusses implications
of specific constraints on the security mechanisms employed. A wider of specific constraints on the security mechanisms employed. A wider
view of security in constrained-node networks is provided in view of security in constrained-node networks is provided in
[I-D.irtf-t2trg-iot-seccons]. [I-D.irtf-t2trg-iot-seccons].
9.1. Physical Attacks on Sensor and Actuator Networks 9.1. Physical Attacks on Sensor and Actuator Networks
The focus of this work is on constrained-node networks consisting of The focus of this work is on constrained-node networks consisting of
skipping to change at page 28, line 45 skipping to change at page 27, line 25
o Unauthorized access to data to and from sensors and actuators, o Unauthorized access to data to and from sensors and actuators,
including eavesdropping and manipulation of data. including eavesdropping and manipulation of data.
o Denial-of-service making the sensor/actuator unable to perform its o Denial-of-service making the sensor/actuator unable to perform its
intended task correctly. intended task correctly.
A number of attacks can be made with physical access to a device A number of attacks can be made with physical access to a device
including probing attacks, timing attacks, power attacks, etc. including probing attacks, timing attacks, power attacks, etc.
However, with physical access to a sensor or actuator device it is However, with physical access to a sensor or actuator device it is
possible to directly perform attacks equivalent of eavesdropping, possible to directly perform attacks equivalent of eavesdropping,
manipulating data or denial of service. For example: manipulating data or denial of service. These attacks are
possible by having physical access to the device, since the assets
o Instead of eavesdropping the sensor data or attacking the are related to the physical world. Moreover, this kind of attacks
authorization system to gain access to the data, the attacker are in many cases straightforward (requires no special competence
could make its own measurements on the physical object. or tools, low cost given physical access, etc). If an attacker
has full physical access to a sensor or actuator device, then much
o Instead of manipulating the sensor data the attacker could change of the security functionality elaborated in this draft may not be
the physical object which the sensor is measuring, thereby effective to protect the asset during the physical attack.
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 9.2. Clocks and Time Measurements
Some applications may require a device to be aware of the wall-clock Measuring time and keeping wall-clock time with certain accuracy is
time (e.g., a door lock that opens Monday to Friday at specific important to achieve certain security properties, for example to
times, except for holidays). Other applications only need to be able determine whether keying material an access token, or some other
to measure short relative time (e.g., a door lock that keeps the door assertion, is valid. The required level of accuracy may differ for
open for ten seconds after receiving a state change to open; such a different applications.
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.
Dynamic authorization in itself requires the ability to handle expiry Dynamic authorization in itself requires the ability to handle expiry
or revocation of authorization decisions or to distinguish new or revocation of authorization decisions or to distinguish new
authorization decisions from old. authorization decisions from old.
For certain categories of devices we can assume that there is an For certain categories of devices we can assume that there is an
internal clock which is sufficiently accurate to handle the time internal clock which is sufficiently accurate to handle the time
measurement requirements. If RS can connect directly to AS, this measurement requirements. If RS continuously measures time and can
relationship can be used to update RS in terms of time, removing some connect directly to AS, this relationship can be used to update RS in
uncertainty, as well as to directly provide revocation information, terms of time, removing some uncertainty, as well as to directly
removing authorizations that are no longer desired. provide revocation information, removing authorizations that are no
longer desired.
If RS continuously measures time but can't connect to AS or another 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 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 be harder to manage revocation. However, RS may still be able to
handle short lived access rights within some margins, by measuring handle short lived access rights within some margins, by measuring
the time since arrival of authorization information or request. the time since arrival of authorization information or request.
Some categories of devices in scope may be unable to measure time Some categories of devices in scope may be unable to measure time
with any accuracy (e.g. because of sleep cycles). This category of with any accuracy (e.g. because of sleep cycles). This category of
devices is not suitable for the use cases which require measuring devices is not suitable for the use cases which require measuring
validity of assertions and authorizations in terms of absolute time. validity of assertions and authorizations in terms of absolute time
such as TLS certificates but require a mechanism that is specifically
designed for them.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. Informative References 11. Informative References
[HUM14delegation] [HUM14delegation]
Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K.
Wehrle, "Delegation-based Authentication and Authorization Wehrle, "Delegation-based Authentication and Authorization
for the IP-based Internet of Things", 11th IEEE for the IP-based Internet of Things", 11th IEEE
International Conference on Sensing, Communication, and International Conference on Sensing, Communication, and
Networking (SECON'14), June 30 - July 3, 2014. 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] [I-D.hardjono-oauth-umacore]
Hardjono, T., Maler, E., Machulak, M., and D. Catalano, Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", draft- "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
hardjono-oauth-umacore-14 (work in progress), January hardjono-oauth-umacore-14 (work in progress), January
2016. 2016.
[I-D.ietf-core-coap-pubsub] [I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in (CoAP)", draft-ietf-core-coap-pubsub-05 (work in
progress), July 2017. progress), July 2018.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-06 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), October 2017. progress), August 2018.
[I-D.irtf-t2trg-iot-seccons] [I-D.irtf-t2trg-iot-seccons]
Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of- Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
the-Art and Challenges for the Internet of Things the-Art and Challenges for the Internet of Things
Security", draft-irtf-t2trg-iot-seccons-08 (work in Security", draft-irtf-t2trg-iot-seccons-15 (work in
progress), October 2017. progress), May 2018.
[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 [REST] Fielding, R. and R. Taylor, "Principled design of the
modern Web architecture", ACM Trans. Inter. Tech. Vol. modern Web architecture", ACM Trans. Inter. Tech. Vol.
2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. 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 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005, DOI 10.17487/RFC4120, July 2005,
<https://www.rfc-editor.org/info/rfc4120>. <https://www.rfc-editor.org/info/rfc4120>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>. <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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
skipping to change at page 32, line 39 skipping to change at page 30, line 11
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
and S. Kumar, "Use Cases for Authentication and and S. Kumar, "Use Cases for Authentication and
Authorization in Constrained Environments", RFC 7744, Authorization in Constrained Environments", RFC 7744,
DOI 10.17487/RFC7744, January 2016, DOI 10.17487/RFC7744, January 2016,
<https://www.rfc-editor.org/info/rfc7744>. <https://www.rfc-editor.org/info/rfc7744>.
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246,
DOI 10.17487/RFC8246, September 2017,
<https://www.rfc-editor.org/info/rfc8246>.
Acknowledgements Acknowledgements
The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
and Erik Wahlstroem for contributing to the discussion, giving and Erik Wahlstroem for contributing to the discussion, giving
helpful input and commenting on previous forms of this draft. The helpful input and commenting on previous forms of this draft. The
authors would also like to specifically acknowledge input provided by authors would also like to specifically acknowledge input provided by
Hummen and others [HUM14delegation]. Robin Wilton provided extensive Hummen and others [HUM14delegation]. Robin Wilton provided extensive
editorial comments that were the basis for significant improvements editorial comments that were the basis for significant improvements
skipping to change at page 33, line 25 skipping to change at page 30, line 47
Ludwig Seitz Ludwig Seitz
RISE SICS RISE SICS
Scheelevaegen 17 Scheelevaegen 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: ludwig.seitz@ri.se Email: ludwig.seitz@ri.se
Goeran Selander Goeran Selander
Ericsson Ericsson AB
Faroegatan 6
Kista 164 80
Sweden
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Carsten Bormann (editor) Carsten Bormann (editor)
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
 End of changes. 65 change blocks. 
326 lines changed or deleted 183 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/