Internet DRAFT - draft-gerdes-ace-actors
draft-gerdes-ace-actors
ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI
Intended status: Informational L. Seitz
Expires: October 31, 2015 SICS Swedish ICT AB
G. Selander
Ericsson
C. Bormann, Ed.
Universitaet Bremen TZI
April 29, 2015
An architecture for authorization in constrained environments
draft-gerdes-ace-actors-05
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 elements of an architecture /
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 http://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 October 31, 2015.
Copyright Notice
Copyright (c) 2015 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 October 31, 2015 [Page 1]
Internet-Draft ace-actors April 2015
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture and High-level Problem Statement . . . . . . . . 5
2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5
2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 7
2.3. Information flows . . . . . . . . . . . . . . . . . . . . 10
2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 11
3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 11
3.1. End-to-End Security Objectives . . . . . . . . . . . . . 12
4. Authentication and Authorization . . . . . . . . . . . . . . 12
5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 14
5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 15
5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 16
5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 16
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 17
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 17
6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 18
6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 18
7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 18
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 19
7.3. Communication Security . . . . . . . . . . . . . . . . . 19
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 20
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 21
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 21
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 22
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 23
8.5. Client-side Authorization Information . . . . . . . . . . 23
8.6. Server-side Authorization Information . . . . . . . . . . 23
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 24
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 24
8.9. Network Considerations . . . . . . . . . . . . . . . . . 25
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 25
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 26
9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
Gerdes, et al. Expires October 31, 2015 [Page 2]
Internet-Draft ace-actors April 2015
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
Constrained nodes are small devices with limited abilities which in
many cases are made to fulfill a specific simple task. They 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.
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.
In some cases authentication and authorization can be addressed by
static configuration provisioned during manufacturing or deployment
by means of fixed trust anchors and 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
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 the access control lists concept may not be
sufficiently generic.
The limitations of the constrained nodes ask 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. In order to meet the security
requirements in constrained scenarios, the necessary tasks need to be
assigned to logical functional entities.
This document provides some terminology, as well as elements of an
architecture to represent the relationships between the logical
functional entities involved; on this basis, a problem description
for authentication and authorization in constrained-node networks is
provided.
Gerdes, et al. Expires October 31, 2015 [Page 3]
Internet-Draft ace-actors April 2015
1.1. Terminology
Readers are required 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].
Terminology for constrained environments including "constrained
device", "constrained-node network", "class 1", etc. are defined in
[RFC7228].
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.
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.
Client (C): An entity which attempts to access a resource on an RS.
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.
Gerdes, et al. Expires October 31, 2015 [Page 4]
Internet-Draft ace-actors April 2015
Authenticated Authorization: A synthesis of mechanisms for
authentication and authorization.
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 client-side authorization, i.e.,
more generally to describe allowed interactions with other endpoints.
2. Architecture and High-level Problem Statement
2.1. Elements of an Architecture
This document deals with how to control and protect resource-based
interaction between potentially constrained endpoints. The following
setting is assumed:
o An endpoint may host functionality of C, RS or both C and RS.
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.
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.
More on the security objectives of the constrained level in
Section 5.1.
-------------- --------------
| ------- | | ------- |
| | C | ------ requests resource -----> | RS | |
| ------- <----- provides resource ------ ------- |
| Endpoint | | Endpoint |
-------------- --------------
Figure 1: Constrained Level
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 C's controlling principal the
Requesting Party (RqP), and calls RS's controlling principal the
Gerdes, et al. Expires October 31, 2015 [Page 5]
Internet-Draft ace-actors April 2015
Resource Owner (RO). Each principal makes authorization decisions
(possibly encapsulating them into security policies) which the
endpoint it controls then enforces.
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 [I-D.ietf-ace-usecases] 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
principal, in turn, requires some agent maintaining the policies
governing how its endpoints will interact.
Gerdes, et al. Expires October 31, 2015 [Page 6]
Internet-Draft ace-actors April 2015
For these reasons, another level of nodes is introduced in the
architecture, the less-constrained level. 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 segregration 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
2.2. Architecture Variants
The elements of the architecture described above are architectural.
In a specific scenario, several elements can 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:
Gerdes, et al. Expires October 31, 2015 [Page 7]
Internet-Draft ace-actors April 2015
------- --------
| 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 October 31, 2015 [Page 8]
Internet-Draft ace-actors April 2015
------- -------
| 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 October 31, 2015 [Page 9]
Internet-Draft ace-actors April 2015
2.3. Information flows
In this subsection, we complement the abstracted architecture
described above with a discussion of the information flows in scope,
mentioning that each endpoint may assume both a client and a server
role and that communication may be via intermediaries.
The less-constrained nodes, CAS and AS, control the interactions
between the endpoints by supporting the potentially constrained nodes
with control information, for example permissions of clients,
conditions on resources, attributes of client and resource servers,
keys and credentials. The control information may be rather
different for C and RS, reflecting the intrinsic asymmetry with C
initiating the request for access to a resource, and RS acting on a
received request, and C finally acting on the received response.
The information flows are shown in Figure 7. The arrows with control
information only indicate origin and destination of information,
actual message flow may pass intermediary nodes (both nodes that are
identified in the architecture and other nodes).
------- ------ ------- ------
| CAS | | AS | | CAS | | AS |
------- ------ ------- ------
| | | |
| | | |
| | control | | control
| | information | | information
| | | |
------------------- -------------------
| | | | | | | |
| v | | | | v
| ------- ---------- request -----------> ------- |
| | C1 | <---------- response ------------ | RS2 | |
| ------- | | | | ------- |
| v | | v |
| ------- | | ------- |
| | RS1 | <---- request ----- | C2 | |
| ------- ----- response ---> ------- |
| | | |
| Endpoint 1 | | Endpoint 2 |
------------------- -------------------
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
Gerdes, et al. Expires October 31, 2015 [Page 10]
Internet-Draft ace-actors April 2015
their associated less-constrained nodes are pre-established, for
example as part of the commissioning procedure.
o The messages between the endpoints also need to be protected,
potentially end-to-end through intermediary nodes (Section 3.1).
Any necessary keys/credentials for protecting the interaction
between the endpoints will need to be established and maintained
as part of a solution.
2.4. Problem statement
The problem statement for authorization in constrained environments
can 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.
3. Security Objectives
The security objectives that are addressed by an authorization
solution include confidentiality and integrity. Additionally,
allowing only selected entities limits the burden on system
resources, thus helping to achieve availability. Misconfigured or
wrongly designed authorization solutions can result in availability
breaches: Users might no longer be able to use data and services as
they are supposed to.
Authentication mechanisms can achieve additional security objectives
such as non-repudiation and accountability. These additional
objectives are not related to authorization and thus are not in scope
of this draft, but may nevertheless be relevant. Non-repudiation and
accountability 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.
Gerdes, et al. Expires October 31, 2015 [Page 11]
Internet-Draft ace-actors April 2015
The security objectives and their relative importance differ for the
various constrained environment applications and use cases
[I-D.ietf-ace-usecases].
In many cases, one participating party has different security
objectives than another. To achieve a security objective of one
party, another party may be required to provide a service. E.g., 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 many cases, the information flows described in Section 2.3 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, these will need to
protect the exchanges end-to-end.
Note that there may also be cases of intermediary nodes that very
much partake in the security objectives to be achieved. What is the
endpoint to which communication needs end-to-end protection is
defined by the use case.
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, e.g. 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
Gerdes, et al. Expires October 31, 2015 [Page 12]
Internet-Draft ace-actors April 2015
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 mechanism 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 (e.g. 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 simply make an encrypted representation available to
anyone [OSCAR]. In this case, controlling read access to that
resource can be reduced to controlling read access to the key;
partially removing access also requires a timely update of the key
for RS and all participants 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
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).
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
Gerdes, et al. Expires October 31, 2015 [Page 13]
Internet-Draft ace-actors April 2015
(principle of least privilege), to ensure the confidentiality and
integrity of resources.
For all 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)
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 cannot be assured if it is possible for an
attacker to modify the message 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
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
Gerdes, et al. Expires October 31, 2015 [Page 14]
Internet-Draft ace-actors April 2015
may be realized as protocols or be internal to such a piece of
software.
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 an entity is an authorized server for 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 the authorization of the requester to access the
requested resource as requested.
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 of 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 October 31, 2015 [Page 15]
Internet-Draft ace-actors April 2015
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 and belong to the same security domain.
RqP is in charge of C, i.e. RqP specifies security policies for C,
e.g. 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 complexity level for actors
is introduced. 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.
o Obtain authorization information about an entity from C's
principal (RqP) and provide it to C.
Gerdes, et al. Expires October 31, 2015 [Page 16]
Internet-Draft ace-actors April 2015
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.
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.
Gerdes, et al. Expires October 31, 2015 [Page 17]
Internet-Draft ace-actors April 2015
Protocols on the constrained level should keep this limitation in
mind.
6.1.1. Cross Level Support Protocols
Protocols which operate between a constrained device on one side and
the corresponding less-constrained device on the other are considered
to be (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
there are no limitations for the use of 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.
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.
Gerdes, et al. Expires October 31, 2015 [Page 18]
Internet-Draft ace-actors April 2015
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 (e.g. 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 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 use cases, authentication and authorization of C may be
implicit, e.g. 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.
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
Gerdes, et al. Expires October 31, 2015 [Page 19]
Internet-Draft ace-actors April 2015
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, e.g.
using [I-D.selander-ace-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.koster-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. Do we want to support solutions based on asymmetric
keys or 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 e.g. 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
must be able to specify a unique client identifier which RS can
verify (using an associated key). One of the use cases of
[I-D.ietf-ace-usecases] describes spontaneous change of access
policies - e.g. 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
Gerdes, et al. Expires October 31, 2015 [Page 20]
Internet-Draft ace-actors April 2015
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.
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.)
* 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
Gerdes, et al. Expires October 31, 2015 [Page 21]
Internet-Draft ace-actors April 2015
* 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.
o Public key cryptography requires additional resources (e.g. 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
expiring authentication and authorization information on devices
which are unable to measure time (cf. section 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 Similary, C needs to authenticate CAS to ensure that the
authorization information and related data comes from the correct
source.
Gerdes, et al. Expires October 31, 2015 [Page 22]
Internet-Draft ace-actors April 2015
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
(e.g. 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.
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.
Gerdes, et al. Expires October 31, 2015 [Page 23]
Internet-Draft ace-actors April 2015
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 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 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
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.
Gerdes, et al. Expires October 31, 2015 [Page 24]
Internet-Draft ace-actors April 2015
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.
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
Gerdes, et al. Expires October 31, 2015 [Page 25]
Internet-Draft ace-actors April 2015
of specific constraints on the security mechanisms employed. A wider
view of security in constrained-node networks is provided in
[I-D.garcia-core-security].
9.1. Physical Attacks on Sensor and Actuator Networks
The focus of this work is on constrained-node networks consisting of
connected 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.
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.)
Gerdes, et al. Expires October 31, 2015 [Page 26]
Internet-Draft ace-actors April 2015
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 is not 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 which are exposed during a physical attack. In
other words, either an attacker does not have physical access to
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. Time Measurements
Measuring 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
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 it could
get updated in terms of time as well as revocation information.
If RS continuously measures time but can't connect to AS or other
trusted source, time drift may have to be accepted and it may not be
able to manage revocation. However, it 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 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.
Gerdes, et al. Expires October 31, 2015 [Page 27]
Internet-Draft ace-actors April 2015
11. Acknowledgements
The authors would like to thank Olaf Bergmann, Robert Cragie, Klaus
Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi,
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].
12. 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.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013.
[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-13 (work in progress), April 2015.
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-03 (work
in progress), March 2015.
[I-D.koster-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-koster-core-coap-pubsub-01 (work in
progress), March 2015.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., and L. Seitz, "March 9, 2015",
draft-selander-ace-object-security-01 (work in progress),
March 2015.
Gerdes, et al. Expires October 31, 2015 [Page 28]
Internet-Draft ace-actors April 2015
[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.
[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, August
2000.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014.
Authors' Addresses
Gerdes, et al. Expires October 31, 2015 [Page 29]
Internet-Draft ace-actors April 2015
Stefanie Gerdes
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63906
Email: gerdes@tzi.org
Ludwig Seitz
SICS Swedish ICT AB
Scheelevaegen 17
Lund 223 70
Sweden
Email: ludwig@sics.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 October 31, 2015 [Page 30]
