draft-ietf-ace-actors-05.txt   draft-ietf-ace-actors-06.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: September 7, 2017 SICS Swedish ICT AB Expires: May 18, 2018 RISE SICS
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
March 06, 2017 November 14, 2017
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-05 draft-ietf-ace-actors-06
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.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2017. This Internet-Draft will expire on May 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 5 skipping to change at page 3, line 5
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27
8.9. Network Considerations . . . . . . . . . . . . . . . . . 27 8.9. Network Considerations . . . . . . . . . . . . . . . . . 27
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28
9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 30
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
As described in [RFC7228], constrained nodes are small devices with As described in [RFC7228], constrained nodes are small devices with
limited abilities which in many cases are made to fulfill a specific limited abilities which in many cases are made to fulfill a specific
simple task. They may have limited hardware resources such as simple task. They may have limited hardware resources such as
processing power, memory, non-volatile storage and transmission processing power, memory, non-volatile storage and transmission
capacity and additionally in most cases do not have user interfaces capacity and additionally in most cases do not have user interfaces
and displays. Due to these constraints, commonly used security and displays. Due to these constraints, commonly used security
protocols are not always easily applicable, or may give rise to protocols are not always easily applicable, or may give rise to
skipping to change at page 11, line 21 skipping to change at page 11, line 21
information flows and the messages embodying them: "RESTful information flows and the messages embodying them: "RESTful
architectures focus on defining interfaces and not components" architectures focus on defining interfaces and not components"
([REST], p. 116).) ([REST], p. 116).)
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
may be rather different for C and RS, reflecting the intrinsic may be rather different for C and RS.
asymmetry with C initiating the request for access to a resource, and
RS acting on a received request, and C finally acting on the received
response.
The potential information flows are shown in Figure 7. The direction The potential information flows are shown in Figure 7. The direction
of the vertical arrows expresses the exertion of control; actual of the vertical arrows expresses the exertion of control; actual
information flow is bidirectional. information flow is bidirectional.
The message flow may pass unprotected paths and thus need to be The message flow may pass unprotected paths and thus need to be
protected, potentially beyond a single REST hop (Section 3.1): protected, potentially beyond a single REST hop (Section 3.1):
------- ------- ------- -------
| CAS | | AS | | CAS | | AS |
skipping to change at page 12, line 33 skipping to change at page 12, line 29
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 (Note that other aspects relevant to secure constrained node
communication such as secure bootstrap or group communication are not communication such as secure bootstrap or group communication are not
specifically addressed by the present document.) specifically addressed by the present document.)
3. Security Objectives 3. Security Objectives
The security objectives that are addressed by an authorization The security objectives that are addressed by an authorization
solution include confidentiality and integrity. Additionally, solution include confidentiality and integrity. Additionally, an
allowing only selected operations by selected entities limits the authorization solution has an impact on the availability: First, by
burden on system resources, thus helping to achieve availability. reducing the load (only accepting selected operations by selected
Misconfigured or wrongly designed authorization solutions can result entities limits the burden on system resources), and second, because
in availability breaches (denial of service): Users might no longer misconfigured or wrongly designed authorization solutions can result
in availability breaches (denial of service) as users might no longer
be able to use data and services as they are supposed to. be able to use data and services as they are supposed to.
Authentication mechanisms can help achieve additional security Authentication mechanisms can help achieve additional security
objectives such as accountability and third-party verifiability. objectives such as accountability and third-party verifiability.
These additional objectives are not directly related to authorization These additional objectives are not directly related to authorization
and thus are not in scope of this draft, but may nevertheless be and thus are not in scope of this draft, but may nevertheless be
relevant. Accountability and third-party verifiability may require relevant. Accountability and third-party verifiability may require
authentication on a device level, if it is necessary to determine authentication on a device level, if it is necessary to determine
which device performed an action. In other cases it may be more which device performed an action. In other cases it may be more
important to find out who is responsible for the device's actions. important to find out who is responsible for the device's actions.
skipping to change at page 14, line 38 skipping to change at page 14, line 36
refer to the required synthesis of mechanisms for authentication and refer to the required synthesis of mechanisms for authentication and
authorization. authorization.
Where used for authorization, the set of authenticated attributes Where used for authorization, the set of authenticated attributes
must be meaningful for this purpose, i.e., authorization decisions must be meaningful for this purpose, i.e., authorization decisions
must be possible based on these attributes. If the authorization must be possible based on these attributes. If the authorization
policy assigns permissions to an individual entity, the set of policy assigns permissions to an individual entity, the set of
authenticated attributes must be suitable to uniquely identify this authenticated attributes must be suitable to uniquely identify this
entity. entity.
In other scenarios, there is often less need to uniquely identify an In scenarios where devices are communicating autonomously there is
individual device: For a principal, the fact that a device belongs to often less need to uniquely identify an individual device: For a
a certain company or that it has a specific type (such as a light principal, the fact that a device belongs to a certain company or
bulb) or location may be more important than that it has a unique that it has a specific type (such as a light bulb) or location may be
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 allow everyone to access an encrypted representation
anyone [OSCAR]. In this case, controlling read access to that of the resource [OSCAR]. In this case, controlling read access to
resource can be reduced to controlling read access to the key; that resource can be reduced to controlling read access to the key;
partially removing future access also requires a timely update of the partially removing future access requires that the resource
key for RS and all participants still authorized.) representation is re-encrypted and the new key is made available to
all participants that are still authorized.)
Principals (RqP and RO) need to decide about the required level of Principals (RqP and RO) need to decide about the required level of
granularity for the authorization. For example, we distinguish granularity for the authorization. For example, we distinguish
device authorization from owner authorization, and flat authorization device authorization from owner authorization, and flat authorization
from unrestricted authorization. In the first case different access from unrestricted authorization. In the first case different access
permissions are granted to individual devices while in the second permissions are granted to individual devices while in the second
case individual owners are authorized. If flat authorization is case individual owners are authorized. If flat authorization is
used, all authenticated entities are implicitly authorized and have used, all authenticated entities are implicitly authorized and have
the same access permissions. Unrestricted authorization for an item the same access permissions. Unrestricted authorization for an item
of interest means that no authorization mechanism is used for of interest means that no authorization mechanism is used for
accessing this resource (not even by authentication) and all entities accessing this resource (not even by authentication) and all entities
skipping to change at page 18, line 15 skipping to change at page 18, line 10
| 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
(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; each principal belongs to the same
security domain as their endpoints.
RqP is in charge of C, i.e. RqP specifies security policies for C, RqP is in charge of C, i.e. RqP specifies security policies for C,
such as with whom C is allowed to communicate. By definition, C and such as with whom C is allowed to communicate. By definition, C and
RqP belong to the same security domain. RqP belong to the same security domain.
RqP must fulfill the following task: RqP must fulfill the following task:
o Configure for C authorization information for sources for R. o Configure for C authorization information for sources for R.
RO is in charge of R and RS. RO specifies authorization policies for RO is in charge of R and RS. RO specifies authorization policies for
skipping to change at page 18, line 40 skipping to change at page 18, line 36
o Configure for RS authorization information for accessing R. o Configure for RS authorization information for accessing R.
(See Figure 2.) (See Figure 2.)
5.3. Less-Constrained Level Actors 5.3. Less-Constrained Level Actors
Constrained level actors can only fulfill a limited number of tasks Constrained level actors can only fulfill a limited number of tasks
and may not have network connectivity all the time. To relieve them and may not have network connectivity all the time. To relieve them
from having to manage keys for numerous endpoints and conducting from having to manage keys for numerous endpoints and conducting
computationally intensive tasks, another complexity level for actors computationally intensive tasks, another level of complexity for
is introduced. An actor on the less-constrained level belongs to the actors is introduced (and, thus, a stricter limit on their
same security domain as its respective constrained level actor. They constrainedness). An actor on the less-constrained level belongs to
also have the same principal. the same security domain as its respective constrained level actor.
They also have the same principal.
The Client Authorization Server (CAS) belongs to the same security The Client Authorization Server (CAS) belongs to the same security
domain as C and RqP. CAS acts on behalf of RqP. It assists C in domain as C and RqP. CAS acts on behalf of RqP. It assists C in
authenticating RS and determining if RS is an authorized server for authenticating RS and determining if RS is an authorized server for
R. CAS can do that because for C, CAS is the authority for claims R. CAS can do that because for C, CAS is the authority for claims
about RS. about RS.
CAS performs the following tasks: CAS performs the following tasks:
o Validate on the client side that an entity has certain attributes. o Validate on the client side that an entity has certain attributes.
skipping to change at page 20, line 15 skipping to change at page 20, line 13
for channel security. for channel security.
Constrained devices have only limited storage space and thus cannot Constrained devices have only limited storage space and thus cannot
store large numbers of keys. This is especially important because store large numbers of keys. This is especially important because
constrained networks are expected to consist of thousands of nodes. constrained networks are expected to consist of thousands of nodes.
Protocols on the constrained level should keep this limitation in Protocols on the constrained level should keep this limitation in
mind. mind.
6.1.1. Cross Level Support Protocols 6.1.1. Cross Level Support Protocols
Protocols which operate between a constrained device on one side and We refer to protocols that operate between a constrained device and
the corresponding less-constrained device on the other are considered its corresponding less-constrained device as cross-level support
to be (cross level) support protocols. Protocols used between C and protocols. Protocols used between C and CAS or RS and AS are
CAS or RS and AS are therefore support protocols. therefore support protocols.
Support protocols must consider the limitations of their constrained Support protocols must consider the limitations of their constrained
endpoint and therefore belong to the constrained level protocols. endpoint and therefore belong to the constrained level protocols.
6.2. Less-Constrained Level Protocols 6.2. Less-Constrained Level Protocols
A protocol is considered to be on the less-constrained level if it is A protocol is considered to be on the less-constrained level if it is
used between the actors CAS and AS. CAS and AS might belong to used between the actors CAS and AS. CAS and AS might belong to
different security domains. different security domains.
On the less-constrained level, HTTP [RFC7230] and Transport Layer On the less-constrained level, HTTP [RFC7230] and Transport Layer
Security (TLS) [RFC5246] can be used alongside or instead of CoAP and Security (TLS) [RFC5246] can be used alongside or instead of CoAP and
DTLS. Moreover, existing security solutions for authentication and DTLS. Moreover, existing security solutions for authentication and
authorization such as the OAuth web authorization framework [RFC6749] authorization such as the OAuth web authorization framework [RFC6749]
and Kerberos [RFC4120] can likely be used without modifications and and Kerberos [RFC4120] can likely be used without modifications and
there are no limitations for the use of a Public Key Infrastructure the less-constrained layer is assumed to impose no constraints that
(PKI). would inhibit the traditional deployment/use of, e.g., a Public Key
Infrastructure (PKI).
7. Elements of a Solution 7. Elements of a Solution
Without anticipating specific solutions, the following considerations Without anticipating specific solutions, the following considerations
may be helpful in discussing them. may be helpful in discussing them.
7.1. Authorization 7.1. Authorization
The core problem we are trying to solve is authorization. The The core problem we are trying to solve is authorization. The
following problems related to authorization need to be addressed: following problems related to authorization need to be addressed:
skipping to change at page 22, line 23 skipping to change at page 22, line 23
protection, for the whole application layer exchange. However, protection, for the whole application layer exchange. However,
DTLS may not provide end-to-end security over multiple hops. DTLS may not provide end-to-end security over multiple hops.
Another problem with DTLS is the cost of the handshake protocol, Another problem with DTLS is the cost of the handshake protocol,
which may be too expensive for constrained devices especially in which may be too expensive for constrained devices especially in
terms of memory and power consumption for message transmissions. terms of memory and power consumption for message transmissions.
o An alternative is object security at application layer, for o An alternative is object security at application layer, for
instance using [I-D.ietf-core-object-security]. Secure objects instance using [I-D.ietf-core-object-security]. Secure objects
can be stored or cached in network nodes and provide security for can be stored or cached in network nodes and provide security for
a more flexible communication model such as publish/subscribe a more flexible communication model such as publish/subscribe
(compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). (compare e.g. CoRE Mirror Server [I-D.ietf-core-coap-pubsub]). A
A problem with object security is that it can not provide 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. It may be necessary to support solutions that
keys or symmetric keys in both cases? There are classes of require the use of asymmetric keys as well as ones that get by
devices that can easily perform symmetric cryptography, but with symmetric keys, in both cases. There are classes of devices
consume considerably more time/battery for asymmetric operations. that can easily perform symmetric cryptography, but consume
On the other hand asymmetric cryptography has benefits such as in considerably more time/battery for asymmetric operations. On the
terms of deployment. other hand asymmetric cryptography has benefits such as in 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
[RFC7744] describes spontaneous change of access policies - such [RFC7744] describes spontaneous change of access policies - such
as giving a hitherto unknown client the right to temporarily as giving a hitherto unknown client the right to temporarily
unlock your house door. In this case C is not previously known to unlock your house door. In this case C is not previously known to
skipping to change at page 23, line 19 skipping to change at page 23, line 20
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
more concise and precise. more concise and precise. Note that many of these assumptions and
requirements are targeting specific solutions and not the
architecture itself.
8.1. Architecture 8.1. Architecture
The architecture consists of at least the following types of nodes: The architecture consists of at least the following types of nodes:
o RS hosting resources, and responding to access requests o RS hosting resources, and responding to access requests
o C requesting access to resources o C requesting access to resources
o AS supporting the access request/response procedure by providing o AS supporting the access request/response procedure by providing
skipping to change at page 24, line 50 skipping to change at page 25, line 7
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.
o A solution will need to consider support for a simple scheme for o A solution will need to consider support for a simple scheme for
expiring authentication and authorization information on devices expiring authentication and authorization information on devices
which are unable to measure time (cf. Section 9.2). which are unable to measure time (cf. Section 9.2).
8.3. Authentication 8.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 Similarly, 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.
skipping to change at page 28, line 23 skipping to change at page 28, line 23
The entire document is about security. Security considerations The entire document is about security. Security considerations
applicable to authentication and authorization in RESTful applicable to authentication and authorization in RESTful
environments are provided in e.g. OAuth 2.0 [RFC6749]. environments are provided in e.g. OAuth 2.0 [RFC6749].
In this section we focus on specific security aspects related to In this section we focus on specific security aspects related to
authorization in constrained-node networks. Section 11.6 of authorization in constrained-node networks. Section 11.6 of
[RFC7252], "Constrained node considerations", discusses implications [RFC7252], "Constrained node considerations", discusses implications
of specific constraints on the security mechanisms employed. A wider of specific constraints on the security mechanisms employed. A wider
view of security in constrained-node networks is provided in view of security in constrained-node networks is provided in
[I-D.garcia-core-security]. [I-D.irtf-t2trg-iot-seccons].
9.1. Physical Attacks on Sensor and Actuator Networks 9.1. Physical Attacks on Sensor and Actuator Networks
The focus of this work is on constrained-node networks consisting of The focus of this work is on constrained-node networks consisting of
connected sensors and actuators. The main function of such devices connected constrained devices such as sensors and actuators. The
is to interact with the physical world by gathering information or main function of such devices is to interact with the physical world
performing an action. We now discuss attacks performed with physical by gathering information or performing an action. We now discuss
access to such devices. attacks performed with physical access to such devices.
The main threats to sensors and actuator networks are: The main threats to sensors and actuator networks are:
o Unauthorized access to data to and from sensors and actuators, o Unauthorized access to data to and from sensors and actuators,
including eavesdropping and manipulation of data. including eavesdropping and manipulation of data.
o Denial-of-service making the sensor/actuator unable to perform its o Denial-of-service making the sensor/actuator unable to perform its
intended task correctly. intended task correctly.
A number of attacks can be made with physical access to a device A number of attacks can be made with physical access to a device
skipping to change at page 29, line 24 skipping to change at page 29, line 24
object or device. object or device.
All these attacks are possible by having physical access to the All these attacks are possible by having physical access to the
device, since the assets are related to the physical world. device, since the assets are related to the physical world.
Moreover, this kind of attacks are in many cases straightforward Moreover, this kind of attacks are in many cases straightforward
(requires no special competence or tools, low cost given physical (requires no special competence or tools, low cost given physical
access, etc.) access, etc.)
As a conclusion, if an attacker has full physical access to a As a conclusion, if an attacker has full physical access to a
sensor or actuator device, then much of the security functionality sensor or actuator device, then much of the security functionality
elaborated in this draft is not effective to protect the asset elaborated in this draft may not be effective to protect the asset
during the physical attack. during the physical attack.
Since it does not make sense to design a solution for a situation Since it does not make sense to design a solution for a situation
that cannot be protected against we assume there is no need to that cannot be protected against we assume there is no need to
protect assets which are exposed during a physical attack. In protect assets the secrets or functioning of which are exposed
other words, either an attacker does not have physical access to during a physical attack. In other words, either an attacker does
the sensor or actuator device, or if it has, the attack shall only not have physical access to the secrets or functioning of the
sensor or actuator device, or if it has, the attack shall only
have effect during the period of physical attack, and shall be have effect during the period of physical attack, and shall be
limited in extent to the physical control the attacker exerts limited in extent to the physical control the attacker exerts
(e.g., must not affect the security of other devices.) (e.g., must not affect the security of other devices.)
9.2. Clocks and Time Measurements 9.2. Clocks and Time Measurements
Measuring time and keeping wall-clock time with certain accuracy is Some applications may require a device to be aware of the wall-clock
important to achieve certain security properties, for example to time (e.g., a door lock that opens Monday to Friday at specific
determine whether a public key certificate, access token, or some times, except for holidays). Other applications only need to be able
other assertion, is valid. to measure short relative time (e.g., a door lock that keeps the door
open for ten seconds after receiving a state change to open; such a
door lock may be limited in its time-keeping accuracy and may not be
able to keep time across power failures).
In addition to application requirements of this kind, measuring time
and keeping wall-clock time with certain accuracy is important to
achieve certain security properties, for example to determine whether
a public key certificate, access token, or some other assertion, is
valid.
Dynamic authorization in itself requires the ability to handle expiry Dynamic authorization in itself requires the ability to handle expiry
or revocation of authorization decisions or to distinguish new or revocation of authorization decisions or to distinguish new
authorization decisions from old. authorization decisions from old.
For certain categories of devices we can assume that there is an For certain categories of devices we can assume that there is an
internal clock which is sufficiently accurate to handle the time internal clock which is sufficiently accurate to handle the time
measurement requirements. If RS can connect directly to AS, this measurement requirements. If RS can connect directly to AS, this
relationship can be used to update RS in terms of time, removing some relationship can be used to update RS in terms of time, removing some
uncertainty, as well as to directly provide revocation information, uncertainty, as well as to directly provide revocation information,
removing authorizations that are no longer desired. removing authorizations that are no longer desired.
If RS continuously measures time but can't connect to AS or another If RS continuously measures time but can't connect to AS or another
trusted source of time, time drift may have to be accepted and it may trusted source of time, time drift may have to be accepted and it may
be harder to manage revocation. However, it may still be able to be harder to manage revocation. However, RS may still be able to
handle short lived access rights within some margins, by measuring handle short lived access rights within some margins, by measuring
the time since arrival of authorization information or request. the time since arrival of authorization information or request.
Some categories of devices in scope may be unable measure time with Some categories of devices in scope may be unable to measure time
any accuracy (e.g. because of sleep cycles). This category of with any accuracy (e.g. because of sleep cycles). This category of
devices is not suitable for the use cases which require measuring devices is not suitable for the use cases which require measuring
validity of assertions and authorizations in terms of absolute time. validity of assertions and authorizations in terms of absolute time.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
11. Informative References 11. Informative References
[HUM14delegation] [HUM14delegation]
Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K.
Wehrle, "Delegation-based Authentication and Authorization Wehrle, "Delegation-based Authentication and Authorization
for the IP-based Internet of Things", 11th IEEE for the IP-based Internet of Things", 11th IEEE
International Conference on Sensing, Communication, and International Conference on Sensing, Communication, and
Networking (SECON'14), June 30 - July 3, 2014. Networking (SECON'14), June 30 - July 3, 2014.
[I-D.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013.
[I-D.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-14 (work in progress), January hardjono-oauth-umacore-14 (work in progress), January
2016. 2016.
[I-D.ietf-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-ietf-core-coap-pubsub-02 (work in
progress), July 2017.
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-ietf-core- "Object Security for Constrained RESTful Environments
object-security-01 (work in progress), December 2016. (OSCORE)", draft-ietf-core-object-security-06 (work in
progress), October 2017.
[I-D.koster-core-coap-pubsub] [I-D.irtf-t2trg-iot-seccons]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Garcia-Morchon, O., Kumar, S., and M. Sethi, "State-of-
Subscribe Broker for the Constrained Application Protocol the-Art and Challenges for the Internet of Things
(CoAP)", draft-koster-core-coap-pubsub-05 (work in Security", draft-irtf-t2trg-iot-seccons-08 (work in
progress), July 2016. progress), October 2017.
[OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A.,
Damon, L., and R. Guizzetti, "OSCAR: Object Security Damon, L., and R. Guizzetti, "OSCAR: Object Security
Architecture for the Internet of Things", CoRR vol. Architecture for the Internet of Things", CoRR vol.
abs/1404.7799, 2014. abs/1404.7799, 2014.
[REST] Fielding, R. and R. Taylor, "Principled design of the [REST] Fielding, R. and R. Taylor, "Principled design of the
modern Web architecture", ACM Trans. Inter. Tech. Vol. modern Web architecture", ACM Trans. Inter. Tech. Vol.
2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. 2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
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, D. Spence, "AAA Authorization Framework", RFC 2904,
DOI 10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000,
<http://www.rfc-editor.org/info/rfc2904>. <https://www.rfc-editor.org/info/rfc2904>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005, DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>. <https://www.rfc-editor.org/info/rfc4120>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <https://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <https://www.rfc-editor.org/info/rfc6749>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[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, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <https://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, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
and S. Kumar, "Use Cases for Authentication and and S. Kumar, "Use Cases for Authentication and
Authorization in Constrained Environments", RFC 7744, Authorization in Constrained Environments", RFC 7744,
DOI 10.17487/RFC7744, January 2016, DOI 10.17487/RFC7744, January 2016,
<http://www.rfc-editor.org/info/rfc7744>. <https://www.rfc-editor.org/info/rfc7744>.
Acknowledgements Acknowledgements
The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel
Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt,
Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis
and Erik Wahlstroem for contributing to the discussion, giving and Erik Wahlstroem for contributing to the discussion, giving
helpful input and commenting on previous forms of this draft. The helpful input and commenting on previous forms of this draft. The
authors would also like to specifically acknowledge input provided by authors would also like to specifically acknowledge input provided by
Hummen and others [HUM14delegation]. Robin Wilton provided extensive Hummen and others [HUM14delegation]. Robin Wilton provided extensive
skipping to change at page 33, line 4 skipping to change at page 33, line 15
Authors' Addresses Authors' Addresses
Stefanie Gerdes Stefanie Gerdes
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63906 Phone: +49-421-218-63906
Email: gerdes@tzi.org Email: gerdes@tzi.org
Ludwig Seitz Ludwig Seitz
SICS Swedish ICT AB RISE SICS
Scheelevaegen 17 Scheelevaegen 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: ludwig@sics.se Email: ludwig.seitz@ri.se
Goeran Selander Goeran Selander
Ericsson Ericsson
Faroegatan 6 Faroegatan 6
Kista 164 80 Kista 164 80
Sweden Sweden
Email: goran.selander@ericsson.com Email: goran.selander@ericsson.com
Carsten Bormann (editor) Carsten Bormann (editor)
 End of changes. 44 change blocks. 
89 lines changed or deleted 107 lines changed or added

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