draft-ietf-ace-actors-01.txt   draft-ietf-ace-actors-02.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational L. Seitz Intended status: Informational L. Seitz
Expires: March 31, 2016 SICS Swedish ICT AB Expires: April 21, 2016 SICS Swedish ICT AB
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
September 28, 2015 October 19, 2015
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-01 draft-ietf-ace-actors-02
Abstract Abstract
Constrained-node networks are networks where some nodes have severe Constrained-node networks are networks where some nodes have severe
constraints on code size, state memory, processing capabilities, user constraints on code size, state memory, processing capabilities, user
interface, power and communication bandwidth (RFC 7228). interface, power and communication bandwidth (RFC 7228).
This document provides terminology, and identifies the elements that This document provides terminology, and identifies the elements that
an architecture needs to address, providing a problem statement, for an architecture needs to address, providing a problem statement, for
authentication and authorization in these networks. authentication and authorization in these networks.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 31, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Architecture and High-level Problem Statement . . . . . . . . 5 2. Architecture and High-level Problem Statement . . . . . . . . 5
2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5
2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8
2.3. Information flows . . . . . . . . . . . . . . . . . . . . 11 2.3. Problem statement . . . . . . . . . . . . . . . . . . . . 11
2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 12
3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12
3.1. End-to-End Security Objectives . . . . . . . . . . . . . 13 3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13
4. Authentication and Authorization . . . . . . . . . . . . . . 13 4. Authentication and Authorization . . . . . . . . . . . . . . 13
5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . 17
6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18
6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . 19
7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20
7.3. Communication Security . . . . . . . . . . . . . . . . . 20 7.3. Communication Security . . . . . . . . . . . . . . . . . 21
7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21
8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22
8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22
8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 22 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . 24
8.6. Server-side Authorization Information . . . . . . . . . . 24 8.6. Server-side Authorization Information . . . . . . . . . . 25
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 25 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 25
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 25 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 . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 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-
volatile storage and transmission capacity and additionally in most volatile storage and transmission capacity and additionally in most
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. Information flows 2.3. Problem statement
In this subsection, we complement the abstracted architecture We now formulate the problem statement in terms of the information
described above with a discussion of the information flows in scope, flows the architecture focuses on.
mentioning that each endpoint may assume both a client and a server
role and that communication may be via intermediaries.
The less-constrained nodes, CAS and AS, control the interactions The interaction with the nodes on the principal level, RO and RqP, is
between the endpoints by supporting the potentially constrained nodes not involving constrained nodes and therefore can employ an existing
with control information, for example permissions of clients, mechanism. The less-constrained nodes, CAS and AS, support the
conditions on resources, attributes of client and resource servers, constrained nodes, C and RS, with control information, for example
keys and credentials. The control information may be rather permissions of clients, conditions on resources, attributes of client
different for C and RS, reflecting the intrinsic asymmetry with C and resource servers, keys and credentials. This control information
initiating the request for access to a resource, and RS acting on a may be rather different for C and RS, reflecting the intrinsic
received request, and C finally acting on the received response. asymmetry with C initiating the request for access to a resource, and
RS acting on a received request, and C finally acting on the received
response.
The information flows are shown in Figure 7. The arrows with control The potential information flows are shown in Figure 7. The direction
information only indicate origin and destination of information, of the vertical arrows expresses the exertion of control; actual
actual message flow may pass intermediary nodes (both nodes that are
identified in the architecture and other nodes). The direction 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
| CAS | | AS | | CAS | | AS | protected, potentially beyond a single REST hop (Section 3.1):
------- ------ ------- ------
| | | | ------- -------
| | | | | CAS | | AS |
| | control | | control ------- -------
| | information | | information a ^ | b a = requests for control info a ^ | b
| | | | | | b = control information | |
------------------- ------------------- | v | v
| | | | | | | | ------- -------
| v | | | | v | C | ------ request -------------------> | RS |
| ------- ---------- request -----------> ------- | | | <----- response ------------------- | |
| | C1 | <---------- response ------------ | RS2 | | ------- -------
| ------- | | | | ------- |
| v | | v |
| ------- | | ------- |
| | RS1 | <---- request ----- | C2 | |
| ------- ----- response ---> ------- |
| | | |
| Endpoint 1 | | Endpoint 2 |
------------------- -------------------
Figure 7: Information flows that need to be protected Figure 7: Information flows that need to be protected
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 The messages between the endpoints also need to be protected, o Any necessary keys/credentials for protecting the interaction
potentially end-to-end through intermediary nodes (Section 3.1). between the potentially constrained nodes will need to be
Any necessary keys/credentials for protecting the interaction established and maintained as part of a solution.
between the endpoints will need to be established and maintained
as part of a solution.
2.4. Problem statement
The problem statement for authorization in constrained environments The problem statement for authorization in constrained environments
can be summarized as follows: can 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
skipping to change at page 13, line 22 skipping to change at page 13, line 5
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.
3.1. End-to-End Security Objectives 3.1. End-to-End Security Objectives in Multi-Hop Scenarios
In many cases, the information flows described in Section 2.3 need to In many cases, the information flows described in Section 2.3 cross
be protected end-to-end. For example, AS may not be connected to RS multiple client-server pairings but still need to be protected end-
(or may not want to exercise such a connection), relying on C for to-end. For example, AS may not be connected to RS (or may not want
transferring authorization information. As the authorization to exercise such a connection), relying on C for transferring
information is related to the permissions granted to C, C must not be authorization information. As the authorization information is
in a position to manipulate this information, which therefore related to the permissions granted to C, C must not be in a position
requires integrity protection on the way between AS and RS. to manipulate this information, which therefore requires integrity
protection on the way between AS and RS.
As another example, resource representations sent between endpoints As another example, resource representations sent between endpoints
may be stored in intermediary nodes, such as caching proxies or pub- may be stored in intermediary nodes, such as caching proxies or pub-
sub brokers. Where these intermediaries cannot be relied on to sub brokers. Where these intermediaries cannot be relied on to
fulfill the security objectives of the endpoints, these will need to fulfill the security objectives of the endpoints, these will need to
protect the exchanges end-to-end. 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. What is the much partake in the security objectives to be achieved. The question
endpoint to which communication needs end-to-end protection is what are the pairs of endpoints between which the communication needs
defined by the use case. end-to-end protection (and which aspect of protection) is defined by
the use case. Two examples of intermediary nodes executing security
functionality:
o To enable a trustworthy publication service, a pub-sub broker may
be untrusted with the plaintext content of a publication
(confidentiality), but required to verify that the publication is
performed by claimed publisher and is not a replay of an old
publication (authenticity/integrity).
o To comply with requirements of transparency, a gateway may be
allowed to read, verify (authenticity) but not modify (integrity)
a resource representation which therefore also is end-to-end
integrity protected from the server towards a client behind the
gateway.
In order to support the required communication and application In order to support the required communication and application
security, keying material needs to be established between the security, keying material needs to be established between the
relevant nodes in the architecture. relevant nodes in the architecture.
4. Authentication and Authorization 4. Authentication and Authorization
Server-side authorization solutions aim at protecting the access to Server-side authorization solutions aim at protecting the access to
items of interest, for instance hardware or software resources or items of interest, for instance hardware or software resources or
data: They enable the resource owner to control who can access it and data: They enable the resource owner to control who can access it and
skipping to change at page 16, line 9 skipping to change at page 16, line 9
Note that actors are a concept to understand the security Note that actors are a concept to understand the security
requirements for constrained devices. The architecture of an actual requirements for constrained devices. The architecture of an actual
solution might differ as long as the security requirements that solution might differ as long as the security requirements that
derive from the relationship between the identified actors are derive from the relationship between the identified actors are
considered. Several actors might share a single device or even be considered. Several actors might share a single device or even be
combined in a single piece of software. Interfaces between actors combined in a single piece of software. Interfaces between actors
may be realized as protocols or be internal to such a piece of may be realized as protocols or be internal to such a piece of
software. software.
A more detailed discussion of the tasks the actors have to perform in
order to achieve specific security objectives is provided in
[I-D.gerdes-ace-tasks].
5.1. Constrained Level Actors 5.1. Constrained Level Actors
As described in the problem statement (see Section 2), either C or RS As described in the problem statement (see Section 2), either C or RS
or both of them may be located on a constrained node. We therefore 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:
skipping to change at page 29, line 30 skipping to change at page 29, line 42
for the IP-based Internet of Things", 11th IEEE for the IP-based Internet of Things", 11th IEEE
International Conference on Sensing, Communication, and International Conference on Sensing, Communication, and
Networking (SECON'14), June 30 - July 3, 2014. Networking (SECON'14), June 30 - July 3, 2014.
[I-D.garcia-core-security] [I-D.garcia-core-security]
Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and
R. Struik, "Security Considerations in the IP-based R. Struik, "Security Considerations in the IP-based
Internet of Things", draft-garcia-core-security-06 (work Internet of Things", draft-garcia-core-security-06 (work
in progress), September 2013. in progress), September 2013.
[I-D.gerdes-ace-tasks]
Gerdes, S., "Authorization-Related Tasks in Constrained
Environments", draft-gerdes-ace-tasks-00 (work in
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-13 (work in progress), April 2015.
[I-D.ietf-ace-usecases] [I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
Kumar, "ACE use cases", draft-ietf-ace-usecases-06 (work Kumar, "ACE use cases", draft-ietf-ace-usecases-09 (work
in progress), September 2015. 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-02 (work in
progress), July 2015. progress), July 2015.
[I-D.selander-ace-object-security] [I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"June 29, 2015", draft-selander-ace-object-security-02 "June 29, 2015", draft-selander-ace-object-security-02
 End of changes. 25 change blocks. 
74 lines changed or deleted 82 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/