draft-ietf-ace-actors-02.txt   draft-ietf-ace-actors-03.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: April 21, 2016 SICS Swedish ICT AB Expires: September 2, 2016 SICS Swedish ICT AB
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
October 19, 2015 March 01, 2016
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-02 draft-ietf-ace-actors-03
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 April 21, 2016. This Internet-Draft will expire on September 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . 5 2. Architecture and High-level Problem Statement . . . . . . . . 6
2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6
2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8
2.3. Problem statement . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 13 4. Authentication and Authorization . . . . . . . . . . . . . . 14
5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16
5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16
5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17
5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 17 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19
6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19
6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19
7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 19 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20
7.3. Communication Security . . . . . . . . . . . . . . . . . 21 7.3. Communication Security . . . . . . . . . . . . . . . . . 21
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24
8.5. Client-side Authorization Information . . . . . . . . . . 24 8.5. Client-side Authorization Information . . . . . . . . . . 25
8.6. Server-side Authorization Information . . . . . . . . . . 25 8.6. Server-side Authorization Information . . . . . . . . . . 25
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 25 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26
8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 26 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27
9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 28 9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. Informative References . . . . . . . . . . . . . . . . . . . 29 12. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 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-
skipping to change at page 3, line 47 skipping to change at page 3, line 47
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. 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 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.
In order to be able to achieve complex security objectives between In order to be able to achieve complex security objectives between
actors some of which are hosted on simple ("constrained") devices, actors some of which are hosted on simple ("constrained") devices,
skipping to change at page 4, line 48 skipping to change at page 4, line 48
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
[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. (Intended to coincide with the definitions of
[RFC7252] and [RFC7231].)
Constrained node: a constrained device in the sense of [RFC7228]. Constrained node: a constrained device in the sense of [RFC7228].
Actor: A logical functional entity that performs one or more tasks. Actor: A logical functional entity that performs one or more tasks.
Multiple actors may be present within a single device or a single Multiple actors may be present within a single device or a single
piece of software. piece of software.
Resource Server (RS): An entity which hosts and represents a Resource Server (RS): An entity which hosts and represents a
Resource. Resource. (Used here to discuss the server that provides a
resource that is the end, not the means, of the authenticated
authorization process - i.e., not CAS or AS.)
Client (C): An entity which attempts to access a resource on an RS. Client (C): An entity which attempts to access a resource on a RS.
(Used to discuss the client whose access to a resource is the end,
not the means, of the authenticated authorization process.)
Principal: (Used in its English sense here, and specifically as:) An Principal: (Used in its English sense here, and specifically as:) An
individual that is either RqP or RO or both. individual that is either RqP or RO or both.
Resource Owner (RO): The principal that is in charge of the resource Resource Owner (RO): The principal that is in charge of the resource
and controls its access permissions. and controls its access permissions.
Requesting Party (RqP): The principal that is in charge of the Requesting Party (RqP): The principal that is in charge of the
Client and controls the requests a Client makes and its acceptance Client and controls the requests a Client makes and its acceptance
of responses. of responses.
Authorization Server (AS): An entity that prepares and endorses Authorization Server (AS): An entity that prepares and endorses
authentication and authorization data for a Resource Server. authentication and authorization data for a Resource Server.
Client Authorization Server (CAS): An entity that prepares and Client Authorization Server (CAS): An entity that prepares and
endorses authentication and authorization data for a Client. endorses authentication and authorization data for a Client.
Authenticated Authorization: A synthesis of mechanisms for Authorization Manager: An entity that prepares and endorses
authentication and authorization. authentication and authorization data for a constrained node.
Used in constructions such as "a constrained node's authorization
manager" to denote AS for RS and CAS for C.
Authenticated Authorization: The confluence of mechanisms for
authentication and authorization, ensuring that authorization is
applied to and made available for authenticated entities and that
entities providing authentication services are authorized to do so
for the specific authorization process at hand.
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 the client-side aspect of this aspect, but is also used for the client-side aspect of
authorization, i.e., more generally to describe allowed interactions authorization, i.e., more generally allowing RqPs to decide what
with other endpoints. interactions clients may perform with other endpoints.
2. Architecture and High-level Problem Statement 2. Architecture and High-level Problem Statement
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 as a high-level problem statement:
o An endpoint may host functionality of one or more actors. 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.
2.1. Elements of an Architecture
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 | |
| ------- <----- provides resource ------ ------- | | ------- <----- provides resource ------ ------- |
| Endpoint | | Endpoint | | Endpoint | | Endpoint |
-------------- -------------- -------------- --------------
Figure 1: Constrained Level Figure 1: Constrained Level
The authorization decisions at the endpoints are made on behalf of The authorization decisions at the endpoints are made on behalf of
the principals that control the endpoints. To reuse OAuth and UMA the principals that control the endpoints. To reuse OAuth and UMA
terminology, the present document calls C's controlling principal the terminology, the present document calls the principal that is
Requesting Party (RqP), and calls RS's controlling principal the controlling C the Requesting Party (RqP), and calls the principal
Resource Owner (RO). Each principal makes authorization decisions that is controlling RS the Resource Owner (RO). Each principal makes
(possibly encapsulating them into security policies) which the authorization decisions (possibly encapsulating them into security
endpoint it controls then enforces. policies) which the endpoint it controls then enforces.
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 18 skipping to change at page 7, line 29
| | | |
in charge of in charge of in charge of in charge of
| | | |
V V V V
------- ------- ------- -------
| C | -- requests resource --> | RS | Constrained Level | C | -- requests resource --> | RS | Constrained Level
------- <-- provides resource-- ------- ------- <-- provides resource-- -------
Figure 2: Constrained Level and Principal Level Figure 2: Constrained Level and Principal Level
The use cases defined in [I-D.ietf-ace-usecases] demonstrate that The use cases defined in [RFC7744] demonstrate that constrained
constrained devices are often used for scenarios where their devices are often used for scenarios where their principals are not
principals are not present at the time of the communication, are not present at the time of the communication, are not able to communicate
able to communicate directly with the device because of a lack of directly with the device because of a lack of user interfaces or
user interfaces or displays, or may prefer the device to communicate displays, or may prefer the device to communicate autonomously.
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. Using OAuth terminology,
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
skipping to change at page 11, line 5 skipping to change at page 11, line 5
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
2.3. Problem statement 2.3. Information Flows
We now formulate the problem statement in terms of the information We now formulate the problem statement in terms of the information
flows the architecture focuses on. flows the architecture focuses on.
The interaction with the nodes on the principal level, RO and RqP, is The interaction with the nodes on the principal level, RO and RqP, is
not involving constrained nodes and therefore can employ an existing not involving constrained nodes and therefore can employ an existing
mechanism. The less-constrained nodes, CAS and AS, support the mechanism. The less-constrained nodes, CAS and AS, support the
constrained nodes, C and RS, with control information, for example constrained nodes, C and RS, with control information, for example
permissions of clients, conditions on resources, attributes of client permissions of clients, conditions on resources, attributes of client
and resource servers, keys and credentials. This control information and resource servers, keys and credentials. This control information
skipping to change at page 11, line 50 skipping to change at page 12, line 5
o We assume that the necessary keys/credentials for protecting the o We assume that the necessary keys/credentials for protecting the
control information between the potentially constrained nodes and control information between the potentially constrained nodes and
their associated less-constrained nodes are pre-established, for their associated less-constrained nodes are pre-established, for
example as part of the commissioning procedure. example as part of the commissioning procedure.
o Any necessary keys/credentials for protecting the interaction o Any necessary keys/credentials for protecting the interaction
between the potentially constrained nodes will need to be between the potentially constrained nodes will need to be
established and maintained as part of a solution. established and maintained as part of a solution.
The problem statement for authorization in constrained environments In terms of the elements of the architecture laid out above, this
can be summarized as follows: document's problem statement for authorization in constrained
environments can then be summarized as follows:
o The interaction between potentially constrained endpoints is o The interaction between potentially constrained endpoints is
controlled by control information provided by less-constrained controlled by control information provided by less-constrained
nodes on behalf of the principals of the endpoints. nodes on behalf of the principals of the endpoints.
o The interaction between the endpoints needs to be secured, as well o The interaction between the endpoints needs to be secured, as well
as the establishment of the necessary keys for securing the as the establishment of the necessary keys for securing the
interaction, potentially end-to-end through intermediary nodes. interaction, potentially end-to-end through intermediary nodes.
o The mechanism for transferring control information needs to be o The mechanism for transferring control information needs to be
secured, potentially end-to-end through intermediary nodes. Pre- secured, potentially end-to-end through intermediary nodes. Pre-
established keying material may need to be employed for established keying material may need to be employed for
establishing the keys used to protect these information flows. establishing the keys used to protect these information flows.
(Note that other aspects relevant to secure constrained node
communication such as secure bootstrap or group communication are not
specifically addressed by the present document.)
3. Security Objectives 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 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 (denial of service): Users might no longer be able to use
they are supposed to. data and services as they are supposed to.
Authentication mechanisms can achieve additional security objectives Authentication mechanisms can achieve additional security objectives
such as accountability and third-party verifiability. These such as accountability and third-party verifiability. These
additional objectives are not directly related to authorization and additional objectives are not directly related to authorization and
thus are not in scope of this draft, but may nevertheless be 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 See also Section 4 for more discussion about authentication and
authorization. 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 [RFC7744].
[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. 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.
skipping to change at page 13, line 26 skipping to change at page 13, line 32
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, these will need to
protect the exchanges beyond a single client-server exchange. 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 use case. Two examples of intermediary nodes executing security the specific use case. Two examples of intermediary nodes executing
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
(confidentiality), but required to verify that the publication is (confidentiality), but required to verify that the publication is
performed by claimed publisher and is not a replay of an old performed by claimed publisher and is not a replay of an old
publication (authenticity/integrity). publication (authenticity/integrity).
o To comply with requirements of transparency, a gateway may be o To comply with requirements of transparency, a gateway may be
allowed to read, verify (authenticity) but not modify (integrity) allowed to read, verify (authenticity) but not modify (integrity)
a resource representation which therefore also is end-to-end a resource representation which therefore also is end-to-end
skipping to change at page 15, line 11 skipping to change at page 15, line 16
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).
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
disclosing information to or ingesting information from resource
servers RqP does not want it to interact with in the given way.
Again, flat authorization (the server can be authenticated) may be
sufficient, or more fine-grained authorization may be required. The
client-side authorization also pertains to the level of protection
required for the exchanges with the server (e.g., confidentiality).
In the browser web, client-side authorization is often left to the
human user; a constrained client may not have that available all the
time but still needs to implement the wishes of the principal
controlling it, the RqP.
For all cases where an authorization solution is needed (all but For all 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 cannot be assured if it is possible for an
attacker to modify the message during transmission. attacker to modify the message 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
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
This and the following section look at the resulting architecture This and the following section look at the resulting architecture
from two different perspectives: This section provides a more from two different perspectives: This section provides a more
detailed description of the various "actors" in the architecture, the detailed description of the various "actors" in the architecture, the
logical functional entities performing the tasks required. The logical functional entities performing the tasks required. The
following section then will focus on the protocols run between these following section then will focus on the protocols run between these
functional entities. functional entities.
skipping to change at page 16, line 26 skipping to change at page 16, line 46
or both of them may be located on a constrained node. We therefore or both of them may be located on a constrained node. We therefore
define that C and RS must be able to perform their tasks even if they define that C and RS must be able to perform their tasks even if they
are located on a constrained node. Thus, C and RS are considered to are located on a constrained node. Thus, C and RS are considered to
be Constrained Level Actors. be Constrained Level Actors.
C performs the following tasks: C performs the following tasks:
o Communicate in a secure way (provide for confidentiality and o Communicate in a secure way (provide for confidentiality and
integrity of messages), including access requests. integrity of messages), including access requests.
o Validate that an entity is an authorized server for R. o Validate that the RqP ("client-side") authorization information
allows C to communicate with RS as a server for R (i.e., from C's
point of view, RS is authorized as a server for the specific
access to R).
RS performs the following tasks: RS performs the following tasks:
o Communicate in a secure way (provide for confidentiality and o Communicate in a secure way (provide for confidentiality and
integrity of messages), including responses to access requests. integrity of messages), including responses to access requests.
o Validate the authorization of the requester to access the o Validate that the RO ("server-side") authorization information
requested resource as requested. allows RS to grant C access to the requested resource as requested
(i.e., from RS' point of view, C is authorized as a client for the
specific access to R).
R is an item of interest such as a sensor or actuator value. R is R is an item of interest such as a sensor or actuator value. R is
considered to be part of RS and not a separate actor. The device on considered to be part of RS and not a separate actor. The device on
which RS is located might contain several resources of different ROs. which RS is located might contain several resources controlled by
For simplicity of exposition, these resources are described as if different ROs. For simplicity of exposition, these resources are
they had separate RS. described as if they had separate RS.
As C and RS do not necessarily know each other they might belong to As C and RS do not necessarily know each other they might belong to
different security domains. different security domains.
(See Figure 8.) (See Figure 8.)
------- -------- ------- --------
| C | -- requests resource ---> | RS | Constrained Level | C | -- requests resource ---> | RS | Constrained Level
------- <-- provides resource--- -------- ------- <-- provides resource--- --------
Figure 8: Constrained Level Actors Figure 8: Constrained Level Actors
5.2. Principal Level Actors 5.2. Principal Level Actors
Our objective is that C and RS are under control of principals in the Our objective is that C and RS are under control of principals in the
physical world, the Requesting Party (RqP) and the Resource Owner physical world, the Requesting Party (RqP) and the Resource Owner
skipping to change at page 20, line 34 skipping to change at page 21, line 5
7.2. Authentication 7.2. Authentication
The following problems need to be addressed, when considering The following problems need to be addressed, when considering
authentication: authentication:
o RS needs to authenticate AS, and C needs to authenticate CAS, to o RS needs to authenticate AS, and C needs to authenticate CAS, to
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 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, for example by encrypting the resource representation implicit, for example by encrypting the resource representation
the RS only providing access to those who possess the key to the RS only providing access to those who possess the key to
decrypt. decrypt.
skipping to change at page 22, line 5 skipping to change at page 22, line 26
consume considerably more time/battery for asymmetric operations. consume considerably more time/battery for asymmetric operations.
On the other hand asymmetric cryptography has benefits such as 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 [RFC7744] describes spontaneous change of access policies - such
policies - such as giving a hitherto unknown client the right to as giving a hitherto unknown client the right to temporarily
temporarily unlock your house door. In this case C is not unlock your house door. In this case C is not previously known to
previously known to RS and a key must be provisioned by AS. 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
In this section we list a set of candidate assumptions and In this section we list a set of candidate assumptions and
requirements to make the problem description in the previous sections requirements to make the problem description in the previous sections
skipping to change at page 23, line 32 skipping to change at page 23, line 51
o CAS and AS are not assumed to be constrained devices. o CAS and AS are not assumed to be constrained devices.
o All devices under consideration can process symmetric cryptography o All devices under consideration can process symmetric cryptography
without incurring an excessive performance penalty. without incurring an excessive performance penalty.
* We assume the use of a standardized symmetric key algorithm, * 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 (which
can be used with the HMAC construction for integrity
protection).
o Public key cryptography requires additional resources (such as o Public key cryptography requires additional resources (such as
RAM, ROM, power, specialized hardware). RAM, ROM, power, specialized hardware).
o A DTLS handshake involves significant computation, communication, 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.
skipping to change at page 24, line 10 skipping to change at page 24, line 28
o A solution will need to consider support for a simple scheme for o A solution will need to consider support for a simple scheme for
expiring authentication and authorization information on devices expiring authentication and authorization information on devices
which are unable to measure time (cf. section Section 9.2). which are unable to measure time (cf. section Section 9.2).
8.3. Authentication 8.3. Authentication
o RS needs to authenticate AS to ensure that the authorization o RS needs to authenticate AS to ensure that the authorization
information and related data comes from the correct source. information and related data comes from the correct source.
o Similary, C needs to authenticate CAS to ensure that the o Similarly, C needs to authenticate CAS to ensure that the
authorization information and related data comes from the correct authorization information and related data comes from the correct
source. source.
o Depending on use case and authorization requirements, C, RS, CAS, o Depending on use case and authorization requirements, C, RS, CAS,
or AS may need to authenticate messages from each other. or AS may need to authenticate messages from each other.
8.4. Server-side Authorization 8.4. Server-side Authorization
o RS enforces authorization for access to a resource based on o RS enforces authorization for access to a resource based on
credentials presented by C, the requested resource, the REST credentials presented by C, the requested resource, the REST
skipping to change at page 25, line 38 skipping to change at page 26, line 7
i.e. information located at a particular URI, accessed with i.e. information located at a particular URI, accessed with
RESTful methods, and the access being subject to the same RESTful methods, and the access being subject to the same
authorization mechanics. AS may have special privileges when authorization mechanics. AS may have special privileges when
requesting access to the authorization policy resources on RS. requesting access to the authorization policy resources on RS.
o There may be mechanisms for C to look up the AS which provides o There may be mechanisms for C to look up the AS which provides
authorization information about a particular resource. authorization information about a particular resource.
8.7. Resource Access 8.7. Resource Access
o Resources are accessed in a RESTful manner using GET, PUT, POST, o Resources are accessed in a RESTful manner using methods such as
DELETE. GET, PUT, POST, DELETE.
o By default, the resource request needs to be integrity protected o By default, the resource request needs to be integrity protected
and may be encrypted end-to-end from C to RS. It needs to be and may be encrypted end-to-end from C to RS. It needs to be
possible for RS to detect a replayed request. possible for RS to detect a replayed request.
o By default, the response to a request needs to be integrity o By default, the response to a request needs to be integrity
protected and encrypted end-to-end from RS to C. It needs to be protected and may be encrypted end-to-end from RS to C. It needs
possible for C to detect a replayed response. to be possible for C to detect a replayed response.
o RS needs to be able to verify that the request comes from an o RS needs to be able to verify that the request comes from an
authorized client authorized client.
o C needs to be able to verify that the response to a request comes o C needs to be able to verify that the response to a request comes
from the intended RS. from the intended RS.
o There may be resources whose access need not be protected (e.g. o There may be resources whose access need not be protected (e.g.
for discovery of the responsible AS). for discovery of the responsible AS).
8.8. Keys and Cipher Suites 8.8. Keys and Cipher Suites
o A constrained node and its authorization manager (i.e., RS and AS, o A constrained node and its authorization manager (i.e., RS and AS,
skipping to change at page 29, line 19 skipping to change at page 29, line 37
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. Acknowledgements
The authors would like to thank Olaf Bergmann, Robert Cragie, Klaus The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi, Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
Hannes Tschofenig, Vlasios Tsiatsis and Erik Wahlstroem for Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
contributing to the discussion, giving helpful input and commenting and Erik Wahlstroem for contributing to the discussion, giving
on previous forms of this draft. The authors would also like to helpful input and commenting on previous forms of this draft. The
specifically acknowledge input provided by Hummen and others authors would also like to specifically acknowledge input provided by
[HUM14delegation]. Hummen and others [HUM14delegation].
12. Informative References 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.
skipping to change at page 29, line 50 skipping to change at page 30, line 19
in progress), September 2013. in progress), September 2013.
[I-D.gerdes-ace-tasks] [I-D.gerdes-ace-tasks]
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-13 (work in progress), April 2015. hardjono-oauth-umacore-14 (work in progress), January
2016.
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-09 (work
in progress), October 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-04 (work in
progress), July 2015. progress), November 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 "Object Security of CoAP (OSCOAP)", draft-selander-ace-
(work in progress), June 2015. object-security-03 (work in progress), October 2015.
[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.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, DOI D. Spence, "AAA Authorization Framework", RFC 2904, DOI
10.17487/RFC2904, August 2000, 10.17487/RFC2904, August 2000,
skipping to change at page 31, line 25 skipping to change at page 31, line 38
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI
10.17487/RFC7231, June 2014, 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014, RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
Authors' Addresses [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
and S. Kumar, "Use Cases for Authentication and
Authorization in Constrained Environments", RFC 7744, DOI
10.17487/RFC7744, January 2016,
<http://www.rfc-editor.org/info/rfc7744>.
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
Ludwig Seitz Ludwig Seitz
 End of changes. 53 change blocks. 
88 lines changed or deleted 125 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/