draft-ietf-ace-actors-00.txt   draft-ietf-ace-actors-01.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: February 26, 2016 SICS Swedish ICT AB Expires: March 31, 2016 SICS Swedish ICT AB
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
August 25, 2015 September 28, 2015
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-00 draft-ietf-ace-actors-01
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 elements of an architecture / This document provides terminology, and identifies the elements that
a problem statement, for authentication and authorization in these an architecture needs to address, providing a problem statement, for
networks. authentication and authorization in these networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 February 26, 2016. This Internet-Draft will expire on March 31, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . 5 2. Architecture and High-level Problem Statement . . . . . . . . 5
2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5
2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 7 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8
2.3. Information flows . . . . . . . . . . . . . . . . . . . . 10 2.3. Information flows . . . . . . . . . . . . . . . . . . . . 11
2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 11 2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 12
3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 11 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12
3.1. End-to-End Security Objectives . . . . . . . . . . . . . 12 3.1. End-to-End Security Objectives . . . . . . . . . . . . . 13
4. Authentication and Authorization . . . . . . . . . . . . . . 12 4. Authentication and Authorization . . . . . . . . . . . . . . 13
5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 14 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15
5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 15 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16
5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 16 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17
5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 16 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 17
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 17 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 17 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18
6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 18 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19
6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 18 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19
7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 18 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 19
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 19 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20
7.3. Communication Security . . . . . . . . . . . . . . . . . 19 7.3. Communication Security . . . . . . . . . . . . . . . . . 20
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 20 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 21 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 21 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 22
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 22 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 23
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 23 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24
8.5. Client-side Authorization Information . . . . . . . . . . 23 8.5. Client-side Authorization Information . . . . . . . . . . 24
8.6. Server-side Authorization Information . . . . . . . . . . 23 8.6. Server-side Authorization Information . . . . . . . . . . 24
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 24 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 25
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 24 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 25
8.9. Network Considerations . . . . . . . . . . . . . . . . . 25 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 25 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 26 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27
9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 27 9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. Informative References . . . . . . . . . . . . . . . . . . . 28 12. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Constrained nodes are small devices with limited abilities which in Constrained nodes are small devices with limited abilities which in
many cases are made to fulfill a specific simple task. They have many cases are made to fulfill a specific simple task. They have
limited hardware resources such as processing power, memory, non- limited hardware resources such as processing power, memory, non-
volatile storage and transmission capacity and additionally in most volatile storage and transmission capacity and additionally in most
cases do not have user interfaces and displays. Due to these cases do not have user interfaces and displays. Due to these
constraints, commonly used security protocols are not always easily constraints, commonly used security protocols are not always easily
applicable. applicable.
Constrained nodes are expected to be integrated in all aspects of Constrained nodes are expected to be integrated in all aspects of
everyday life and thus will be entrusted with vast amounts of data. everyday life and thus will be entrusted with vast amounts of data.
Without appropriate security mechanisms attackers might gain control Without appropriate security mechanisms attackers might gain control
over things relevant to our lives. Authentication and authorization over things relevant to our lives. Authentication and authorization
mechanisms are therefore prerequisites for a secure Internet of mechanisms are therefore prerequisites for a secure Internet of
Things. Things.
Authorization is about who can do what to which objects.
Authentication specifically addresses the who, but is often specific
to the authorization that is required (for example, it may be
sufficient to authenticate the age of an actor, so no identifier is
needed or even desired). Authentication often involves credentials,
only some of which need to be long-lived and generic; others may be
directed towards specific authorizations (but still possibly long-
lived). Authorization then makes use of these credentials, as well
as other information (such as the time of day). This means that the
application-induced complexity of authenticated authorization can
often be moved back and forth between these two aspects.
In some cases authentication and authorization can be addressed by 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 access control lists. This is by means of fixed trust anchors and static access control lists.
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
privileges cannot be conclusively defined during deployment, without specific privileges cannot be conclusively defined during deployment,
any need for change during the lifetime of the device. Moreover, without any need for change during the lifetime of the device.
several use cases illustrate the need for fine-grained access control Moreover, several use cases illustrate the need for fine-grained
policies, for which the access control lists concept may not be access control policies, for which for instance a basic access
sufficiently generic. control list concept may not be sufficiently powerful.
The limitations of the constrained nodes ask for security mechanisms The limitations of the constrained nodes ask for security mechanisms
which take the special characteristics of constrained environments which take the special characteristics of constrained environments
into account; not all constituents may be able to perform all into account; not all constituents may be able to perform all
necessary tasks by themselves. In order to meet the security necessary tasks by themselves. In order to meet the security
requirements in constrained scenarios, the necessary tasks need to be requirements in constrained scenarios, the necessary tasks need to be
assigned to logical functional entities. assigned to logical functional entities.
This document provides some terminology, as well as elements of an In order to be able to achieve complex security objectives between
architecture to represent the relationships between the logical actors some of which are hosted on simple ("constrained") devices,
functional entities involved; on this basis, a problem description some of the actors will make use of help from other, less constrained
for authentication and authorization in constrained-node networks is actors. (This offloading is not specific to networks with
provided. constrained nodes, but their constrainedness as the main motivation
is.)
We therefore group the logical functional entities by whether they
can be assigned to a constrained device ("constrained level") or need
higher function platforms ("less-constrained level"); the latter does
not necessarily mean high-function, "server" or "cloud" platforms.
Note that assigning a logical functional entity to the constrained
level does not mean that the specific implementation needs to be
constrained, only that it _can_ be.
This document provides some terminology, and identifies the elements
an architecture needs to address, representing the relationships
between the logical functional entities involved; on this basis, a
problem description for authentication and authorization in
constrained-node networks is provided.
1.1. Terminology 1.1. Terminology
Readers are required to be familiar with the terms and concepts Readers are required 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]. understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter
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. are defined in device", "constrained-node network", "class 1", etc. is defined in
[RFC7228]. [RFC7228].
In addition, this document uses the following terminology: In addition, this document uses the following terminology:
Resource (R): an item of interest which is represented through an Resource (R): an item of interest which is represented through an
interface. It might contain sensor or actuator values or other interface. It might contain sensor or actuator values or other
information. information.
Constrained node: a constrained device in the sense of [RFC7228]. Constrained node: a constrained device in the sense of [RFC7228].
skipping to change at page 5, line 12 skipping to change at page 5, line 37
Client Authorization Server (CAS): An entity that prepares and Client Authorization Server (CAS): An entity that prepares and
endorses authentication and authorization data for a Client. endorses authentication and authorization data for a Client.
Authenticated Authorization: A synthesis of mechanisms for Authenticated Authorization: A synthesis of mechanisms for
authentication and authorization. authentication and authorization.
Note that other authorization architectures such as OAuth [RFC6749] Note that other authorization architectures such as OAuth [RFC6749]
or UMA [I-D.hardjono-oauth-umacore] focus on the authorization or UMA [I-D.hardjono-oauth-umacore] focus on the authorization
problems on the RS side, in particular what accesses to resources the problems on the RS side, in particular what accesses to resources the
RS is to allow. In this document the term authorization includes RS is to allow. In this document the term authorization includes
this aspect, but is also used for client-side authorization, i.e., this aspect, but is also used for the client-side aspect of
more generally to describe allowed interactions with other endpoints. authorization, i.e., more generally to describe allowed interactions
with other endpoints.
2. Architecture and High-level Problem Statement 2. Architecture and High-level Problem Statement
2.1. Elements of an Architecture 2.1. Elements of an Architecture
This document deals with how to control and protect resource-based This document deals with how to control and protect resource-based
interaction between potentially constrained endpoints. The following interaction between potentially constrained endpoints. The following
setting is assumed: setting is assumed:
o An endpoint may host functionality of C, RS or both C and RS. o An endpoint may host functionality of one or more actors.
o C in one endpoint requests to access R on a RS in another 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.
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.
More on the security objectives of the constrained level 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 | |
| ------- <----- provides resource ------ ------- | | ------- <----- provides resource ------ ------- |
| Endpoint | | Endpoint | | Endpoint | | Endpoint |
-------------- -------------- -------------- --------------
Figure 1: Constrained Level Figure 1: Constrained Level
skipping to change at page 7, line 17 skipping to change at page 7, line 43
AS acts on behalf of the RO to control and support the RS in handling AS acts on behalf of the RO to control and support the RS in handling
access requests, employing a pre-existing security relationship with access requests, employing a pre-existing security relationship with
RS. We complement this with CAS acting on behalf of RqP to control 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 and support the C in making resource requests and acting on the
responses received, employing a pre-existing security relationship responses received, employing a pre-existing security relationship
with C. To further relieve the constrained level, authorization (and with C. To further relieve the constrained level, authorization (and
related authentication) mechanisms may be employed between CAS and AS related authentication) mechanisms may be employed between CAS and AS
(Section 6.2). (Again, both CAS and AS are conceptual entities (Section 6.2). (Again, both CAS and AS are conceptual entities
controlled by their respective principals. Many of these entities, controlled by their respective principals. Many of these entities,
often acting for different principals, can be combined into a single often acting for different principals, can be combined into a single
server implementation; this of course requires proper segregration of server implementation; this of course requires proper segregation of
the control information provided by each principal.) 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 7, line 42 skipping to change at page 8, line 26
authentication authentication authentication authentication
and authorization and authorization and authorization and authorization
| | | |
V V V V
------- ------- ------- -------
| C | -- requests resource --> | RS | Constrained Level | C | -- requests resource --> | RS | Constrained Level
------- <-- provides resource-- ------- ------- <-- provides resource-- -------
Figure 3: Overall architecture Figure 3: Overall architecture
Figure 3 shows all three levels considered in this document. Note
that the vertical arrows point down to illustrate exerting control
and providing support; this is complemented by information flows that
often are bidirectional. Note also that not all entities need to be
ready to communicate at any point in time; for instance, RqP may have
provided enough information to CAS that CAS can autonomously
negotiate access to RS with AS for C based on this information.
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 architectural.
In a specific scenario, several elements can share a single device or 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 even be combined in a single piece of software. If C is located on a
more powerful device, it can be combined with CAS: more powerful device, it can be combined with CAS:
------- -------- ------- --------
| RqP | | RO | Principal Level | RqP | | RO | Principal Level
------- -------- ------- --------
skipping to change at page 9, line 40 skipping to change at page 10, line 40
| RqP = RO | Principal Level | RqP = RO | Principal Level
------------ ------------
| |
in charge of in charge of
| |
V V
-------------- --------------
| CAS + AS | Less-Constrained Level | CAS + AS | Less-Constrained Level
-------------- --------------
/ \ / \
/ \ / \
authentication authentication authentication authentication
and authorization and authorization and authorization and authorization
support support support support
/ \ / \
V V V V
------- ------- ------- -------
| C | -- requests resource --> | RS | Constrained Level | C | -- requests resource --> | RS | Constrained Level
------- <-- provides resource -- ------- ------- <-- provides resource -- -------
Figure 6: CAS combined with AS Figure 6: CAS combined with AS
skipping to change at page 10, line 24 skipping to change at page 11, line 24
with control information, for example permissions of clients, with control information, for example permissions of clients,
conditions on resources, attributes of client and resource servers, conditions on resources, attributes of client and resource servers,
keys and credentials. The control information may be rather keys and credentials. The control information may be rather
different for C and RS, reflecting the intrinsic asymmetry with C different for C and RS, reflecting the intrinsic asymmetry with C
initiating the request for access to a resource, and RS acting on a initiating the request for access to a resource, and RS acting on a
received request, and C finally acting on the received response. received request, and C finally acting on the received response.
The information flows are shown in Figure 7. The arrows with control The information flows are shown in Figure 7. The arrows with control
information only indicate origin and destination of information, information only indicate origin and destination of information,
actual message flow may pass intermediary nodes (both nodes that are actual message flow may pass intermediary nodes (both nodes that are
identified in the architecture and other nodes). identified in the architecture and other nodes). The direction of
the vertical arrows expresses the exertion of control; actual
information flow is bidirectional.
------- ------ ------- ------ ------- ------ ------- ------
| CAS | | AS | | CAS | | AS | | CAS | | AS | | CAS | | AS |
------- ------ ------- ------ ------- ------ ------- ------
| | | | | | | |
| | | | | | | |
| | control | | control | | control | | control
| | information | | information | | information | | information
| | | | | | | |
------------------- ------------------- ------------------- -------------------
skipping to change at page 11, line 42 skipping to change at page 12, line 45
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 entities limits the burden on system
resources, thus helping to achieve availability. Misconfigured or resources, thus helping to achieve availability. Misconfigured or
wrongly designed authorization solutions can result in availability wrongly designed authorization solutions can result in availability
breaches: Users might no longer be able to use data and services as breaches: Users might no longer be able to use data and services as
they are supposed to. they are supposed to.
Authentication mechanisms can achieve additional security objectives Authentication mechanisms can achieve additional security objectives
such as non-repudiation and accountability. These additional such as accountability and third-party verifiability. These
objectives are not related to authorization and thus are not in scope additional objectives are not directly related to authorization and
of this draft, but may nevertheless be relevant. Non-repudiation and thus are not in scope of this draft, but may nevertheless be
accountability may require authentication on a device level, if it is relevant. Accountability and third-party verifiability may require
necessary to determine which device performed an action. In other authentication on a device level, if it is necessary to determine
cases it may be more important to find out who is responsible for the which device performed an action. In other cases it may be more
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
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 various constrained environment applications and use cases
[I-D.ietf-ace-usecases]. [I-D.ietf-ace-usecases].
In many cases, one participating party has different security In many cases, one participating party has different security
objectives than another. To achieve a security objective of one objectives than another. To achieve a security objective of one
party, another party may be required to provide a service. E.g., if party, another party may be required to provide a service. For
RqP requires the integrity of representations of a resource R that RS example, if RqP requires the integrity of representations of a
is hosting, both C and RS need to partake in integrity-protecting the resource R that RS is hosting, both C and RS need to partake in
transmitted data. Moreover, RS needs to protect any write access to integrity-protecting the transmitted data. Moreover, RS needs to
this resource as well as to relevant other resources (such as protect any write access to this resource as well as to relevant
configuration information, firmware update resources) to prevent other resources (such as configuration information, firmware update
unauthorized users from manipulating R. resources) to prevent unauthorized users from manipulating R.
3.1. End-to-End Security Objectives 3.1. End-to-End Security Objectives
In many cases, the information flows described in Section 2.3 need to 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 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 (or may not want to exercise such a connection), relying on C for
transferring authorization information. As the authorization transferring authorization information. As the authorization
information is related to the permissions granted to C, C must not be information is related to the permissions granted to C, C must not be
in a position to manipulate this information, which therefore in a position to manipulate this information, which therefore
requires integrity protection on the way between AS and RS. requires integrity protection on the way between AS and RS.
skipping to change at page 12, line 47 skipping to change at page 13, line 50
endpoint to which communication needs end-to-end protection is endpoint to which communication needs end-to-end protection is
defined by the use case. defined by the use case.
In order to support the required communication and application In order to support the required communication and application
security, keying material needs to be established between the security, keying material needs to be established between the
relevant nodes in the architecture. relevant nodes in the architecture.
4. Authentication and Authorization 4. Authentication and Authorization
Server-side authorization solutions aim at protecting the access to Server-side authorization solutions aim at protecting the access to
items of interest, e.g. hardware or software resources or data: They items of interest, for instance hardware or software resources or
enable the resource owner to control who can access it and how. 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 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
skipping to change at page 13, line 24 skipping to change at page 14, line 28
Where used for authorization, the set of authenticated attributes Where used for authorization, the set of authenticated attributes
must be meaningful for this purpose, i.e., authorization decisions must be meaningful for this purpose, i.e., authorization decisions
must be possible based on these attributes. If the authorization must be possible based on these attributes. If the authorization
policy assigns permissions to an individual entity, the set of policy assigns permissions to an individual entity, the set of
authenticated attributes must be suitable to uniquely identify this authenticated attributes must be suitable to uniquely identify this
entity. entity.
In scenarios where devices are communicating autonomously there is In scenarios where devices are communicating autonomously there is
often less need to uniquely identify an individual device: For a often less need to uniquely identify an individual device: For a
principal, the fact that a device belongs to a certain company or 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 that it has a specific type (such as a light bulb) or location may be
important than that it has a unique identifier. more important than that it has a unique 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 access also requires a timely update of the key
for RS and all participants still authorized.) 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
skipping to change at page 16, line 13 skipping to change at page 17, line 13
Figure 8: Constrained Level Actors Figure 8: Constrained Level Actors
5.2. Principal Level Actors 5.2. Principal Level Actors
Our objective is that C and RS are under control of principals in the Our objective is that C and RS are under control of principals in the
physical world, the Requesting Party (RqP) and the Resource Owner physical world, the Requesting Party (RqP) and the Resource Owner
(RO) respectively. The principals decide about the security policies (RO) respectively. The principals decide about the security policies
of their respective endpoints and belong to the same security domain. 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, 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 such as with whom C is allowed to communicate. By definition, C and
belong to the same security domain. RqP belong to the same security domain.
RqP must fulfill the following task: RqP must fulfill the following task:
o Configure for C authorization information for sources for R. o Configure for C authorization information for sources for R.
RO is in charge of R and RS. RO specifies authorization policies for RO is in charge of R and RS. RO specifies authorization policies for
R and decides with whom RS is allowed to communicate. By definition, R and decides with whom RS is allowed to communicate. By definition,
R, RS and RO belong to the same security domain. R, RS and RO belong to the same security domain.
RO must fulfill the following task: RO must fulfill the following task:
skipping to change at page 19, line 8 skipping to change at page 20, line 8
constrained devices, considering size of authorization information constrained devices, considering size of authorization information
and parser complexity. and parser complexity.
o C and RS need to be able to verify the authenticity of the o C and RS need to be able to verify the authenticity of the
authorization information they receive. Here as well, there is a authorization information they receive. Here as well, there is a
trade-off between processing complexity and deployment complexity. trade-off between processing complexity and deployment complexity.
o The RS needs to enforce the authorization decisions of the AS, o The RS needs to enforce the authorization decisions of the AS,
while C needs to abide with the authorization decisions of the while C needs to abide with the authorization decisions of the
CAS. The authorization information might require additional CAS. The authorization information might require additional
policy evaluation (e.g. matching against local access control policy evaluation (such as matching against local access control
lists, evaluating local conditions). The required "policy lists, evaluating local conditions). The required "policy
evaluation" at the constrained actors needs to be adapted to the evaluation" at the constrained actors needs to be adapted to the
capabilities of the devices implementing them. capabilities of the devices implementing them.
o Finally, as is indicated in the previous bullet, for a particular o Finally, as is indicated in the previous bullet, for a particular
authorization decision there may be different kinds of authorization decision there may be different kinds of
authorization information needed, and these pieces of information authorization information needed, and these pieces of information
may be transferred to C and RS at different times and in different may be transferred to C and RS at different times and in different
ways prior to or during the client request. ways prior to or during the client request.
skipping to change at page 19, line 35 skipping to change at page 20, line 35
ensure that the authorization information and related data comes ensure that the authorization information and related data comes
from the correct source. from the correct source.
o CAS and AS may need to to authenticate each other, both to perform 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 the required business logic and to ensure that CAS gets security
information related to the resources from the right source. information related to the resources from the right source.
o In some use cases RS needs to authenticate some property of C, in o In some use cases RS needs to authenticate some property of C, in
order to map it to the relevant authorization information. In order to map it to the relevant authorization information. In
other use cases, authentication and authorization of C may be other use cases, authentication and authorization of C may be
implicit, e.g. by encrypting the resource representation the RS implicit, for example by encrypting the resource representation
only providing access to those who possess the key to decrypt. the RS only providing access to those who possess the key to
decrypt.
o C may need to authenticate RS, in order to ensure that it is o C may need to authenticate RS, in order to ensure that it is
interacting with the right resources. Alternatively C may just interacting with the right resources. Alternatively C may just
verify the integrity of a received resource representation. verify the integrity of a received resource representation.
o CAS and AS need to authenticate their communication partner (C or o CAS and AS need to authenticate their communication partner (C or
RS), in order to ensure it serves the correct device. RS), in order to ensure it serves the correct device.
7.3. Communication Security 7.3. Communication Security
skipping to change at page 20, line 10 skipping to change at page 21, line 13
We list the available alternatives: We list the available alternatives:
o Session-based security at transport layer such as DTLS [RFC6347] o Session-based security at transport layer such as DTLS [RFC6347]
offers security, including integrity and confidentiality offers security, including integrity and confidentiality
protection, for the whole application layer exchange. However, protection, for the whole application layer exchange. However,
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, e.g. o An alternative is object security at application layer, for
using [I-D.selander-ace-object-security]. Secure objects can be instance using [I-D.selander-ace-object-security]. Secure objects
stored or cached in network nodes and provide security for a more can be stored or cached in network nodes and provide security for
flexible communication model such as publish/subscribe (compare a more flexible communication model such as publish/subscribe
e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). A (compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]).
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
protected by session-based security. protected by session-based security.
7.4. Cryptographic Keys 7.4. Cryptographic Keys
With respect to cryptographic keys, we see the following problems With respect to cryptographic keys, we see the following problems
that need to be addressed: that need to be addressed:
Symmetric vs Asymmetric Keys Symmetric vs Asymmetric Keys
We need keys both for protection of resource access and for We need keys both for protection of resource access and for
protection of transport of authentication and authorization protection of transport of authentication and authorization
information. Do we want to support solutions based on asymmetric information. Do we want to support solutions based on asymmetric
keys or symmetric keys in both cases? There are classes of keys or symmetric keys in both cases? There are classes of
devices that can easily perform symmetric cryptography, but devices that can easily perform symmetric cryptography, but
consume considerably more time/battery for asymmetric operations. consume considerably more time/battery for asymmetric operations.
On the other hand asymmetric cryptography has benefits e.g. in On the other hand asymmetric cryptography has benefits such as in
terms of deployment. terms of deployment.
Key Establishment Key Establishment
How are the corresponding cryptographic keys established? How are the corresponding cryptographic keys established?
Considering Section 7.1 there must be a mapping between these keys Considering Section 7.1 there must be a mapping between these keys
and the authorization information, at least in the sense that AS and the authorization information, at least in the sense that AS
must be able to specify a unique client identifier which RS can must be able to specify a unique client identifier which RS can
verify (using an associated key). One of the use cases of verify (using an associated key). One of the use cases of
[I-D.ietf-ace-usecases] describes spontaneous change of access [I-D.ietf-ace-usecases] describes spontaneous change of access
policies - e.g. giving a hitherto unknown client the right to policies - such as giving a hitherto unknown client the right to
temporarily unlock your house door. In this case C is not temporarily unlock your house door. In this case C is not
previously known to RS and a key must be provisioned by AS. previously known to RS and a key must be provisioned by AS.
Revocation and Expiration Revocation and Expiration
How are keys replaced and how is a key that has been compromised How are keys replaced and how is a key that has been compromised
revoked in a manner that reaches all affected parties, also revoked in a manner that reaches all affected parties, also
keeping in mind scenarios with intermittent connectivity? keeping in mind scenarios with intermittent connectivity?
8. Assumptions and Requirements 8. Assumptions and Requirements
skipping to change at page 22, line 26 skipping to change at page 23, line 26
o All devices under consideration can process symmetric cryptography o All devices under consideration can process symmetric cryptography
without incurring an excessive performance penalty. without incurring an excessive performance penalty.
* We assume the use of a standardized symmetric key algorithm, * We assume the use of a standardized symmetric key algorithm,
such as AES. such as AES.
* Except for the most constrained devices we assume the use of a * Except for the most constrained devices we assume the use of a
standardized cryptographic hash function such as SHA-256. standardized cryptographic hash function such as SHA-256.
o Public key cryptography requires additional resources (e.g. RAM, o Public key cryptography requires additional resources (such as
ROM, power, specialized hardware). RAM, ROM, power, specialized hardware).
o A DTLS handshake involves significant computation, communication, o A DTLS handshake involves significant computation, communication,
and memory overheads in the context of constrained devices. and memory overheads in the context of constrained devices.
* The RAM requirements of DTLS handshakes with public key * The RAM requirements of DTLS handshakes with public key
cryptography are prohibitive for certain constrained devices. cryptography are prohibitive for certain constrained devices.
* Certificate-based DTLS handshakes require significant volumes * Certificate-based DTLS handshakes require significant volumes
of communication, RAM (message buffers) and computation. of communication, RAM (message buffers) and computation.
skipping to change at page 23, line 29 skipping to change at page 24, line 29
o The authorization decision is enforced by RS. o The authorization decision is enforced by RS.
* RS needs to have authorization information in order to verify * RS needs to have authorization information in order to verify
that C is allowed to access the resource as requested. that C is allowed to access the resource as requested.
* RS needs to make sure that it provides resource access only to * RS needs to make sure that it provides resource access only to
authorized clients. authorized clients.
o Apart from authorization for access to a resource, authorization o Apart from authorization for access to a resource, authorization
may also be required for access to information about a resource may also be required for access to information about a resource
(e.g. resource descriptions). (for instance, resource descriptions).
o The solution may need to be able to support the delegation of o The solution may need to be able to support the delegation of
access rights. access rights.
8.5. Client-side Authorization Information 8.5. Client-side Authorization Information
o C enforces client-side authorization by protecting its requests to o C enforces client-side authorization by protecting its requests to
RS and by authenticating results from RS, making use of decisions RS and by authenticating results from RS, making use of decisions
and policies as well as keying material provided by CAS. and policies as well as keying material provided by CAS.
skipping to change at page 28, line 37 skipping to change at page 29, line 37
Internet of Things", draft-garcia-core-security-06 (work Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013. in progress), September 2013.
[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-13 (work in progress), April 2015. hardjono-oauth-umacore-13 (work in progress), April 2015.
[I-D.ietf-ace-usecases] [I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-04 (work Kumar, "ACE use cases", draft-ietf-ace-usecases-06 (work
in progress), June 2015. in progress), September 2015.
[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-02 (work in (CoAP)", draft-koster-core-coap-pubsub-02 (work in
progress), July 2015. progress), July 2015.
[I-D.selander-ace-object-security] [I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"June 29, 2015", draft-selander-ace-object-security-02 "June 29, 2015", draft-selander-ace-object-security-02
 End of changes. 33 change blocks. 
102 lines changed or deleted 146 lines changed or added

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