< draft-ietf-ace-actors-04.txt   draft-ietf-ace-actors-05.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: March 4, 2017 SICS Swedish ICT AB Expires: September 7, 2017 SICS Swedish ICT AB
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
August 31, 2016 March 06, 2017
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-04 draft-ietf-ace-actors-05
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 4, 2017. This Internet-Draft will expire on September 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . 8 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 9
2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11 2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11
3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 16 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 17
5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18
5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19
6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20
6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20
7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 21
7.3. Communication Security . . . . . . . . . . . . . . . . . 21 7.3. Communication Security . . . . . . . . . . . . . . . . . 22
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 23
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 23
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 24
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 25
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 25
8.5. Client-side Authorization Information . . . . . . . . . . 25 8.5. Client-side Authorization Information . . . . . . . . . . 25
8.6. Server-side Authorization Information . . . . . . . . . . 25 8.6. Server-side Authorization Information . . . . . . . . . . 26
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27
8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 8.9. Network Considerations . . . . . . . . . . . . . . . . . 27
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28
9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Informative References . . . . . . . . . . . . . . . . . . . 30
12. Informative References . . . . . . . . . . . . . . . . . . . 29 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Constrained nodes are small devices with limited abilities which in As described in [RFC7228], constrained nodes are small devices with
many cases are made to fulfill a specific simple task. They have limited abilities which in many cases are made to fulfill a specific
limited hardware resources such as processing power, memory, non- simple task. They may have limited hardware resources such as
volatile storage and transmission capacity and additionally in most processing power, memory, non-volatile storage and transmission
cases do not have user interfaces and displays. Due to these capacity and additionally in most cases do not have user interfaces
constraints, commonly used security protocols are not always easily and displays. Due to these constraints, commonly used security
applicable. protocols are not always easily applicable, or may give rise to
particular deployment/management challenges.
Constrained nodes are expected to be integrated in all aspects of As components of the Internet of Things (IoT), constrained nodes are
everyday life and thus will be entrusted with vast amounts of data. expected to be integrated in all aspects of everyday life and thus
Without appropriate security mechanisms attackers might gain control will be entrusted with vast amounts of data. Without appropriate
over things relevant to our lives. Authentication and authorization security mechanisms attackers might gain control over things relevant
mechanisms are therefore prerequisites for a secure Internet of to our lives. Authentication and authorization mechanisms are
Things. therefore prerequisites for a secure Internet of Things.
Authorization is about who can do what to which objects. Applications generally require some degree of authentication and
authorization, which gives rise to some complexity. Authorization is
about who can do what to which objects (see also [RFC4949]).
Authentication specifically addresses the who, but is often specific Authentication specifically addresses the who, but is often specific
to the authorization that is required (for example, it may be to the authorization that is required (for example, it may be
sufficient to authenticate the age of an actor, so no identifier is sufficient to authenticate the age of an actor, so no identifier is
needed or even desired). Authentication often involves credentials, needed or even desired). Authentication often involves credentials,
only some of which need to be long-lived and generic; others may be only some of which need to be long-lived and generic; others may be
directed towards specific authorizations (but still possibly long- directed towards specific authorizations (but still possibly long-
lived). Authorization then makes use of these credentials, as well lived). Authorization then makes use of these credentials, as well
as other information (such as the time of day). This means that the as other information (such as the time of day). This means that the
application-induced complexity of authenticated authorization can complexity of authenticated authorization can often be moved back and
often be moved back and forth between these two aspects. forth between these two aspects.
In some cases authentication and authorization can be addressed by In some cases authentication and authorization can be addressed by
static configuration provisioned during manufacturing or deployment static configuration provisioned during manufacturing or deployment
by means of fixed trust anchors and static access control lists. by means of fixed trust anchors and static access control lists.
This is particularly applicable to siloed, fixed-purpose deployments. This is particularly applicable to siloed, fixed-purpose deployments.
However, as the need for flexible access to assets already deployed However, as the need for flexible access to assets already deployed
increases, the legitimate set of authorized entities as well as their increases, the legitimate set of authorized entities as well as their
specific privileges cannot be conclusively defined during deployment, specific privileges cannot be conclusively defined during deployment,
without any need for change during the lifetime of the device. without any need for change during the lifetime of the device.
Moreover, several use cases illustrate the need for fine-grained Moreover, several use cases illustrate the need for fine-grained
access control policies, for which for instance a basic access access control policies, for which for instance a basic access
control list concept may not be sufficiently powerful [RFC7744]. control list concept may not be sufficiently powerful [RFC7744].
The limitations of the constrained nodes ask for security mechanisms The limitations of the constrained nodes impose a need for security
which take the special characteristics of constrained environments mechanisms which take the special characteristics of constrained
into account; not all constituents may be able to perform all environments into account; not all constituents may be able to
necessary tasks by themselves. In order to meet the security perform all necessary tasks by themselves. To put it the other way
requirements in constrained scenarios, the necessary tasks need to be round: the security mechanisms that protect constrained nodes must
assigned to logical functional entities. remain effective and manageable despite the limitations imposed by
the constrained environment.
In order to be able to achieve complex security objectives between Therefore, in order to be able to achieve complex security objectives
actors some of which are hosted on simple ("constrained") devices, between actors some of which are hosted on simple ("constrained")
some of the actors will make use of help from other, less constrained devices, some of the actors will make use of help from other, less
actors. (This offloading is not specific to networks with constrained actors. (This offloading is not specific to networks
constrained nodes, but their constrainedness as the main motivation with constrained nodes, but their constrainedness as the main
is.) motivation is.)
We therefore group the logical functional entities by whether they We therefore group the logical functional entities by whether they
can be assigned to a constrained device ("constrained level") or need can be assigned to a constrained device ("constrained level") or need
higher function platforms ("less-constrained level"); the latter does higher function platforms ("less-constrained level"); the latter does
not necessarily mean high-function, "server" or "cloud" platforms. not necessarily mean high-function, "server" or "cloud" platforms.
Note that assigning a logical functional entity to the constrained Note that assigning a logical functional entity to the constrained
level does not mean that the specific implementation needs to be level does not mean that the specific implementation needs to be
constrained, only that it _can_ be. constrained, only that it _can_ be.
The description assumes that some form of setup (aspects of which are The description assumes that some form of setup (aspects of which are
skipping to change at page 4, line 36 skipping to change at page 4, line 41
for making the system operational have already been established. for making the system operational have already been established.
This document provides some terminology, and identifies the elements This document provides some terminology, and identifies the elements
an architecture needs to address, representing the relationships an architecture needs to address, representing the relationships
between the logical functional entities involved; on this basis, a between the logical functional entities involved; on this basis, a
problem description for authentication and authorization in problem description for authentication and authorization in
constrained-node networks is provided. constrained-node networks is provided.
1.1. Terminology 1.1. Terminology
Readers are required to be familiar with the terms and concepts Readers are assumed to be familiar with the terms and concepts
defined in [RFC4949], including "authentication", "authorization", defined in [RFC4949], including "authentication", "authorization",
"confidentiality", "(data) integrity", "message authentication code", "confidentiality", "(data) integrity", "message authentication code",
and "verify". and "verify".
REST terms including "resource", "representation", etc. are to be REST terms including "resource", "representation", etc. are to be
understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter
also defines additional terms such as "endpoint". also defines additional terms such as "endpoint".
Terminology for constrained environments including "constrained Terminology for constrained environments including "constrained
device", "constrained-node network", "class 1", etc. is defined in device", "constrained-node network", "class 1", etc. is defined in
skipping to change at page 6, line 31 skipping to change at page 6, line 31
o C in one endpoint requests to access R on a RS in another o C in one endpoint requests to access R on a RS in another
endpoint. endpoint.
o A priori, the endpoints do not necessarily have a pre-existing o A priori, the endpoints do not necessarily have a pre-existing
security relationship to each other. security relationship to each other.
o Either of the endpoints, or both, may be constrained. o Either of the endpoints, or both, may be constrained.
2.1. Elements of an Architecture 2.1. Elements of an Architecture
In its simplest expression, the architecture starts with a two-layer
model: the principal level (at which components are assumed to be
functionally unconstrained) and the constrained level (at which some
functional constraints are assumed to apply to the components).
Without loss of generality, we focus on the C functionality in one Without loss of generality, we focus on the C functionality in one
endpoint, which we therefore also call C, accessing the RS endpoint, which we therefore also call C, accessing the RS
functionality in another endpoint, which we therefore also call RS. functionality in another endpoint, which we therefore also call RS.
The constrained level and its security objectives are detailed in The constrained level and its security objectives are detailed in
Section 5.1. Section 5.1.
-------------- -------------- -------------- --------------
| ------- | | ------- | | ------- | | ------- |
| | C | ------ requests resource -----> | RS | | | | C | ------ requests resource -----> | RS | |
skipping to change at page 7, line 5 skipping to change at page 7, line 11
-------------- -------------- -------------- --------------
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 principals that control the endpoints. To reuse OAuth and UMA
terminology, the present document calls the principal that is terminology, the present document calls the principal that is
controlling C the Requesting Party (RqP), and calls the principal controlling C the Requesting Party (RqP), and calls the principal
that is controlling RS the Resource Owner (RO). Each principal makes that is controlling RS the Resource Owner (RO). Each principal makes
authorization decisions (possibly encapsulating them into security authorization decisions (possibly encapsulating them into security
policies) which the endpoint it controls then enforces. 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 50 skipping to change at page 8, line 8
directly with the device because of a lack of user interfaces or directly with the device because of a lack of user interfaces or
displays, or may prefer the device to communicate autonomously. 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 a principal. The
principal, in turn, requires some agent maintaining the policies principal, in turn, requires some agent maintaining the policies
governing how its endpoints will interact. 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. Using OAuth terminology, architecture, the less-constrained level (illustrated below in
AS acts on behalf of the RO to control and support the RS in handling Figure 3). Using OAuth terminology, AS acts on behalf of the RO to
access requests, employing a pre-existing security relationship with control and support the RS in handling access requests, employing a
RS. We complement this with CAS acting on behalf of RqP to control pre-existing security relationship with RS. We complement this with
and support the C in making resource requests and acting on the CAS acting on behalf of RqP to control and support the C in making
responses received, employing a pre-existing security relationship resource requests and acting on the responses received, employing a
with C. To further relieve the constrained level, authorization (and pre-existing security relationship with C. To further relieve the
related authentication) mechanisms may be employed between CAS and AS constrained level, authorization (and related authentication)
(Section 6.2). (Again, both CAS and AS are conceptual entities mechanisms may be employed between CAS and AS (Section 6.2). (Again,
controlled by their respective principals. Many of these entities, both CAS and AS are conceptual entities controlled by their
often acting for different principals, can be combined into a single respective principals. Many of these entities, often acting for
server implementation; this of course requires proper segregation of different principals, can be combined into a single server
the control information provided by each principal.) implementation; this of course requires proper segregation of the
control information provided by each 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 8, line 48 skipping to change at page 9, line 7
Figure 3 shows all three levels considered in this document. Note Figure 3 shows all three levels considered in this document. Note
that the vertical arrows point down to illustrate exerting control that the vertical arrows point down to illustrate exerting control
and providing support; this is complemented by information flows that and providing support; this is complemented by information flows that
often are bidirectional. Note also that not all entities need to be often are bidirectional. Note also that not all entities need to be
ready to communicate at any point in time; for instance, RqP may have ready to communicate at any point in time; for instance, RqP may have
provided enough information to CAS that CAS can autonomously provided enough information to CAS that CAS can autonomously
negotiate access to RS with AS for C based on this information. negotiate access to RS with AS for C based on this information.
2.2. Architecture Variants 2.2. Architecture Variants
The elements of the architecture described above are architectural. The elements of the architecture described above are indeed
In a specific scenario, several elements can share a single device or architectural; that is, they are parts of a conceptual model, and may
even be combined in a single piece of software. If C is located on a be instantiated in various ways in practice. For example, in a given
more powerful device, it can be combined with CAS: scenario, several elements might share a single device or even be
combined in a single piece of software. If C is located on a more
powerful device, it can be combined with CAS:
------- -------- ------- --------
| RqP | | RO | Principal Level | RqP | | RO | Principal Level
------- -------- ------- --------
| | | |
in charge of in charge of in charge of in charge of
| | | |
V V V V
------------ -------- ------------ --------
| CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level
skipping to change at page 12, line 34 skipping to change at page 12, line 34
establishing the keys used to protect these information flows. establishing the keys used to protect these information flows.
(Note that other aspects relevant to secure constrained node (Note that other aspects relevant to secure constrained node
communication such as secure bootstrap or group communication are not communication such as secure bootstrap or group communication are not
specifically addressed by the present document.) specifically addressed by the present document.)
3. Security Objectives 3. Security Objectives
The security objectives that are addressed by an authorization The security objectives that are addressed by an authorization
solution include confidentiality and integrity. Additionally, solution include confidentiality and integrity. Additionally,
allowing only selected entities limits the burden on system allowing only selected operations by selected entities limits the
resources, thus helping to achieve availability. Misconfigured or burden on system resources, thus helping to achieve availability.
wrongly designed authorization solutions can result in availability Misconfigured or wrongly designed authorization solutions can result
breaches (denial of service): Users might no longer be able to use in availability breaches (denial of service): Users might no longer
data and services as they are supposed to. be able to use data and services as they are supposed to.
Authentication mechanisms can achieve additional security objectives Authentication mechanisms can help achieve additional security
such as accountability and third-party verifiability. These objectives such as accountability and third-party verifiability.
additional objectives are not directly related to authorization and These additional objectives are not directly related to authorization
thus are not in scope of this draft, but may nevertheless be and thus are not in scope of this draft, but may nevertheless be
relevant. Accountability and third-party verifiability may require relevant. Accountability and third-party verifiability may require
authentication on a device level, if it is necessary to determine authentication on a device level, if it is necessary to determine
which device performed an action. In other cases it may be more which device performed an action. In other cases it may be more
important to find out who is responsible for the device's actions. important to find out who is responsible for the device's actions.
See also Section 4 for more discussion about authentication and (The ensuing requirements for logging, auditability, and the related
authorization. integrity requirements are very relevant for constrained devices as
well, but outside the scope of this document.) See also Section 4
for more discussion about authentication and authorization.
The security objectives and their relative importance differ for the The security objectives and their relative importance differ for the
various constrained environment applications and use cases [RFC7744]. various constrained environment applications and use cases [RFC7744].
In many cases, one participating party has different security The architecture is based on the observation that different parties
objectives than another. To achieve a security objective of one may have different security objectives. There may also be a
"collaborative" dimension: to achieve a security objective of one
party, another party may be required to provide a service. For party, another party may be required to provide a service. For
example, if RqP requires the integrity of representations of a example, if RqP requires the integrity of representations of a
resource R that RS is hosting, both C and RS need to partake in resource R that RS is hosting, both C and RS need to partake in
integrity-protecting the transmitted data. Moreover, RS needs to integrity-protecting the transmitted data. Moreover, RS needs to
protect any write access to this resource as well as to relevant protect any write access to this resource as well as to relevant
other resources (such as configuration information, firmware update other resources (such as configuration information, firmware update
resources) to prevent unauthorized users from manipulating R. resources) to prevent unauthorized users from manipulating R.
3.1. End-to-End Security Objectives in Multi-Hop Scenarios 3.1. End-to-End Security Objectives in Multi-Hop Scenarios
skipping to change at page 13, line 29 skipping to change at page 13, line 33
to-end. For example, AS may not be connected to RS (or may not want 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 to exercise such a connection), relying on C for transferring
authorization information. As the authorization information is authorization information. As the authorization information is
related to the permissions granted to C, C must not be in a position related to the permissions granted to C, C must not be in a position
to manipulate this information, which therefore requires integrity to manipulate this information, which therefore requires integrity
protection on the way between AS and RS. protection on the way between AS and RS.
As another example, resource representations sent between endpoints As another example, resource representations sent between endpoints
may be stored in intermediary nodes, such as caching proxies or pub- may be stored in intermediary nodes, such as caching proxies or pub-
sub brokers. Where these intermediaries cannot be relied on to sub brokers. Where these intermediaries cannot be relied on to
fulfill the security objectives of the endpoints, these will need to fulfill the security objectives of the endpoints, it is the endpoints
protect the exchanges beyond a single client-server exchange. that will need to protect the exchanges beyond a single client-server
exchange.
Note that there may also be cases of intermediary nodes that very Note that there may also be cases of intermediary nodes that very
much partake in the security objectives to be achieved. The question much partake in the security objectives to be achieved. The question
what are the pairs of endpoints between which the communication needs what are the pairs of endpoints between which the communication needs
end-to-end protection (and which aspect of protection) is defined by end-to-end protection (and which aspect of protection) is defined by
the specific use case. Two examples of intermediary nodes executing the specific use case. Two examples of intermediary nodes executing
security functionality: security functionality:
o To enable a trustworthy publication service, a pub-sub broker may o To enable a trustworthy publication service, a pub-sub broker may
be untrusted with the plaintext content of a publication be untrusted with the plaintext content of a publication
skipping to change at page 14, line 26 skipping to change at page 14, line 28
To determine if an entity is authorized to access a resource, an To determine if an entity is authorized to access a resource, an
authentication mechanism is needed. According to the Internet authentication mechanism is needed. According to the Internet
Security Glossary [RFC4949], authentication is "the process of Security Glossary [RFC4949], authentication is "the process of
verifying a claim that a system entity or system resource has a verifying a claim that a system entity or system resource has a
certain attribute value." Examples for attribute values are the ID certain attribute value." Examples for attribute values are the ID
of a device, the type of the device or the name of its owner. of a device, the type of the device or the name of its owner.
The security objectives the authorization mechanism aims at can only The security objectives the authorization mechanism aims at can only
be achieved if the authentication and the authorization mechanism be achieved if the authentication and the authorization mechanism
work together correctly. We speak of authenticated authorization to work together correctly. We speak of authenticated authorization to
refer to the required synthesis of mechanism for authentication and refer to the required synthesis of mechanisms for authentication and
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 other scenarios, there is often less need to uniquely identify an
often less need to uniquely identify an individual device: For a individual device: For a principal, the fact that a device belongs to
principal, the fact that a device belongs to a certain company or a certain company or that it has a specific type (such as a light
that it has a specific type (such as a light bulb) or location may be bulb) or location may be more important than that it has a unique
more important than that it has a unique identifier. identifier.
(As a special case for the authorization of read access to a (As a special case for the authorization of read access to a
resource, RS may simply make an encrypted representation available to resource, RS may simply make an encrypted representation available to
anyone [OSCAR]. In this case, controlling read access to that anyone [OSCAR]. In this case, controlling read access to that
resource can be reduced to controlling read access to the key; resource can be reduced to controlling read access to the key;
partially removing access also requires a timely update of the key partially removing future access also requires a timely update of the
for RS and all participants still authorized.) key for RS and all participants still authorized.)
Principals (RqP and RO) need to decide about the required level of Principals (RqP and RO) need to decide about the required level of
granularity for the authorization. For example, we distinguish granularity for the authorization. For example, we distinguish
device authorization from owner authorization, and flat authorization device authorization from owner authorization, and flat authorization
from unrestricted authorization. In the first case different access from unrestricted authorization. In the first case different access
permissions are granted to individual devices while in the second permissions are granted to individual devices while in the second
case individual owners are authorized. If flat authorization is case individual owners are authorized. If flat authorization is
used, all authenticated entities are implicitly authorized and have used, all authenticated entities are implicitly authorized and have
the same access permissions. Unrestricted authorization for an item the same access permissions. Unrestricted authorization for an item
of interest means that no authorization mechanism is used for of interest means that no authorization mechanism is used for
accessing this resource (not even by authentication) and all entities accessing this resource (not even by authentication) and all entities
are able to access the item as they see fit (note that an are able to access the item as they see fit (note that an
authorization mechanism may still be used to arrive at the decision authorization mechanism may still be used to arrive at the decision
to employ unrestricted authorization). to employ unrestricted authorization).
+-----------------+-------------------------------------------------+
| Authorization | Authorization is contingent on: |
| granularity | |
+-----------------+-------------------------------------------------+
| device | authentication of specific device |
| | |
| owner | (authenticated) authorization by owner |
| | |
| flat | (any) authentication |
| | |
| unrestricted | (unrestricted access; access always authorized) |
+-----------------+-------------------------------------------------+
Table 1: Some granularity levels for authorization
More fine-grained authorization does not necessarily provide more 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. Principals need to consider that
an entity should only be granted the permissions it really needs an entity should only be granted the permissions it really needs
(principle of least privilege), to ensure the confidentiality and (principle of least privilege), to ensure the confidentiality and
integrity of resources. 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, flat 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; a constrained client may not have that available all the
time but still needs to implement the wishes of the principal time but still needs to implement the wishes of the principal
controlling it, the RqP. controlling it, the RqP.
For all 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 cannot be assured if it is possible for an required: Authenticity of the message cannot be assured if it is
attacker to modify the message 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. Principals
may decide to omit authentication (unrestricted authorization), or may decide to omit authentication (unrestricted authorization), or
use flat authorization (just employing an authentication mechanism). use flat authorization (just employing an authentication mechanism).
However, as indicated in Section 3, the security objectives of both However, as indicated in Section 3, the security objectives of both
sides must be considered, which can often only be achieved when the sides must be considered, which can often only be achieved when the
other side can be relied on to perform some security service. other side can be relied on to perform some security service.
5. Actors and their Tasks 5. Actors and their Tasks
skipping to change at page 21, line 42 skipping to change at page 22, line 20
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,
DTLS may not provide end-to-end security over multiple hops. DTLS may not provide end-to-end security over multiple hops.
Another problem with DTLS is the cost of the handshake protocol, Another problem with DTLS is the cost of the handshake protocol,
which may be too expensive for constrained devices especially in which may be too expensive for constrained devices especially in
terms of memory and power consumption for message transmissions. terms of memory and power consumption for message transmissions.
o An alternative is object security at application layer, for o An alternative is object security at application layer, for
instance using [I-D.selander-ace-object-security]. Secure objects instance using [I-D.ietf-core-object-security]. Secure objects
can be stored or cached in network nodes and provide security for can be stored or cached in network nodes and provide security for
a more flexible communication model such as publish/subscribe a more flexible communication model such as publish/subscribe
(compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). (compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]).
A problem with object security is that it can not provide A problem with object security is that it can not provide
confidentiality for the message headers. confidentiality for the message headers.
o Hybrid solutions using both session-based and object security are o Hybrid solutions using both session-based and object security are
also possible. An example of a hybrid is where authorization also possible. An example of a hybrid is where authorization
information and cryptographic keys are provided by AS in the information and cryptographic keys are provided by AS in the
format of secure data objects, but where the resource access is format of secure data objects, but where the resource access is
skipping to change at page 29, line 38 skipping to change at page 30, line 20
Some categories of devices in scope may be unable measure time with Some categories of devices in scope may be unable measure time with
any accuracy (e.g. because of sleep cycles). This category of 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.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. Acknowledgements 11. Informative References
The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
and Erik Wahlstroem for contributing to the discussion, giving
helpful input and commenting on previous forms of this draft. The
authors would also like to specifically acknowledge input provided by
Hummen and others [HUM14delegation].
12. 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.garcia-core-security] [I-D.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
skipping to change at page 30, line 29 skipping to change at page 30, line 46
Gerdes, S., "Authorization-Related Tasks in Constrained Gerdes, S., "Authorization-Related Tasks in Constrained
Environments", draft-gerdes-ace-tasks-00 (work in Environments", draft-gerdes-ace-tasks-00 (work in
progress), September 2015. 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-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core-
object-security-01 (work in progress), December 2016.
[I-D.koster-core-coap-pubsub] [I-D.koster-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-koster-core-coap-pubsub-05 (work in (CoAP)", draft-koster-core-coap-pubsub-05 (work in
progress), July 2016. progress), July 2016.
[I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-05 (work in progress), July 2016.
[OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A.,
Damon, L., and R. Guizzetti, "OSCAR: Object Security Damon, L., and R. Guizzetti, "OSCAR: Object Security
Architecture for the Internet of Things", CoRR vol. Architecture for the Internet of Things", CoRR vol.
abs/1404.7799, 2014. 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., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
skipping to change at page 32, line 11 skipping to change at page 32, line 26
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://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,
<http://www.rfc-editor.org/info/rfc7744>. <http://www.rfc-editor.org/info/rfc7744>.
Acknowledgements
The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
and Erik Wahlstroem for contributing to the discussion, giving
helpful input and commenting on previous forms of this draft. The
authors would also like to specifically acknowledge input provided by
Hummen and others [HUM14delegation]. Robin Wilton provided extensive
editorial comments that were the basis for significant improvements
of the text.
Authors' Addresses Authors' Addresses
Stefanie Gerdes Stefanie Gerdes
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63906 Phone: +49-421-218-63906
Email: gerdes@tzi.org Email: gerdes@tzi.org
 End of changes. 42 change blocks. 
117 lines changed or deleted 149 lines changed or added

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