--- 1/draft-ietf-ace-actors-01.txt 2015-10-19 06:15:10.744719986 -0700 +++ 2/draft-ietf-ace-actors-02.txt 2015-10-19 06:15:10.804721434 -0700 @@ -1,23 +1,23 @@ ACE Working Group S. Gerdes Internet-Draft Universitaet Bremen TZI Intended status: Informational L. Seitz -Expires: March 31, 2016 SICS Swedish ICT AB +Expires: April 21, 2016 SICS Swedish ICT AB G. Selander Ericsson C. Bormann, Ed. Universitaet Bremen TZI - September 28, 2015 + October 19, 2015 An architecture for authorization in constrained environments - draft-ietf-ace-actors-01 + draft-ietf-ace-actors-02 Abstract Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks. @@ -30,21 +30,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -54,53 +54,52 @@ the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture and High-level Problem Statement . . . . . . . . 5 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 - 2.3. Information flows . . . . . . . . . . . . . . . . . . . . 11 - 2.4. Problem statement . . . . . . . . . . . . . . . . . . . . 12 + 2.3. Problem statement . . . . . . . . . . . . . . . . . . . . 11 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 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 17 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 19 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 - 7.3. Communication Security . . . . . . . . . . . . . . . . . 20 + 7.3. Communication Security . . . . . . . . . . . . . . . . . 21 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 - 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 22 - 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 23 + 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23 + 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 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.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 25 + 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.9. Network 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.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 28 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Informative References . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction Constrained nodes are small devices with limited abilities which in many cases are made to fulfill a specific simple task. They have limited hardware resources such as processing power, memory, non- volatile storage and transmission capacity and additionally in most @@ -430,79 +429,64 @@ and authorization and authorization support support / \ V V ------- ------- | C | -- requests resource --> | RS | Constrained Level ------- <-- provides resource -- ------- Figure 6: CAS combined with AS -2.3. Information flows +2.3. Problem statement - In this subsection, we complement the abstracted architecture - described above with a discussion of the information flows in scope, - mentioning that each endpoint may assume both a client and a server - role and that communication may be via intermediaries. + We now formulate the problem statement in terms of the information + flows the architecture focuses on. - The less-constrained nodes, CAS and AS, control the interactions - between the endpoints by supporting the potentially constrained nodes - with control information, for example permissions of clients, - conditions on resources, attributes of client and resource servers, - keys and credentials. The control information may be rather - different for C and RS, reflecting the intrinsic 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 interaction with the nodes on the principal level, RO and RqP, is + not involving constrained nodes and therefore can employ an existing + mechanism. The less-constrained nodes, CAS and AS, support the + constrained nodes, C and RS, with control information, for example + permissions of clients, conditions on resources, attributes of client + and resource servers, keys and credentials. This control information + may be rather different for C and RS, reflecting the intrinsic + 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 - information only indicate origin and destination of information, - 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 + The potential information flows are shown in Figure 7. The direction + of the vertical arrows expresses the exertion of control; actual information flow is bidirectional. - ------- ------ ------- ------ - | CAS | | AS | | CAS | | AS | - ------- ------ ------- ------ - | | | | - | | | | - | | control | | control - | | information | | information - | | | | - ------------------- ------------------- - | | | | | | | | - | v | | | | v - | ------- ---------- request -----------> ------- | - | | C1 | <---------- response ------------ | RS2 | | - | ------- | | | | ------- | - | v | | v | - | ------- | | ------- | - | | RS1 | <---- request ----- | C2 | | - | ------- ----- response ---> ------- | - | | | | - | Endpoint 1 | | Endpoint 2 | - ------------------- ------------------- + The message flow may pass unprotected paths and thus need to be + protected, potentially beyond a single REST hop (Section 3.1): + + ------- ------- + | CAS | | AS | + ------- ------- + a ^ | b a = requests for control info a ^ | b + | | b = control information | | + | v | v + ------- ------- + | C | ------ request -------------------> | RS | + | | <----- response ------------------- | | + ------- ------- Figure 7: Information flows that need to be protected o We assume that the necessary keys/credentials for protecting the control information between the potentially constrained nodes and their associated less-constrained nodes are pre-established, for example as part of the commissioning procedure. - o The messages between the endpoints also need to be protected, - potentially end-to-end through intermediary nodes (Section 3.1). - Any necessary keys/credentials for protecting the interaction - between the endpoints will need to be established and maintained - as part of a solution. - -2.4. Problem statement + o Any necessary keys/credentials for protecting the interaction + between the potentially constrained nodes will need to be + established and maintained as part of a solution. The problem statement for authorization in constrained environments can be summarized as follows: o The interaction between potentially constrained endpoints is controlled by control information provided by less-constrained nodes on behalf of the principals of the endpoints. o The interaction between the endpoints needs to be secured, as well as the establishment of the necessary keys for securing the @@ -542,40 +525,55 @@ In many cases, one participating party has different security objectives than another. To achieve a security objective of one party, another party may be required to provide a service. For example, if RqP requires the integrity of representations of a resource R that RS is hosting, both C and RS need to partake in integrity-protecting the transmitted data. Moreover, RS needs to protect any write access to this resource as well as to relevant other resources (such as configuration information, firmware update 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 - be protected end-to-end. For example, AS may not be connected to RS - (or may not want to exercise such a connection), relying on C for - transferring authorization information. As the authorization - information is related to the permissions granted to C, C must not be - in a position to manipulate this information, which therefore - requires integrity protection on the way between AS and RS. + In many cases, the information flows described in Section 2.3 cross + multiple client-server pairings but still need to be protected end- + to-end. For example, AS may not be connected to RS (or may not want + to exercise such a connection), relying on C for transferring + authorization information. As the authorization information is + related to the permissions granted to C, C must not be in a position + to manipulate this information, which therefore requires integrity + protection on the way between AS and RS. As another example, resource representations sent between endpoints may be stored in intermediary nodes, such as caching proxies or pub- sub brokers. Where these intermediaries cannot be relied on 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 - much partake in the security objectives to be achieved. What is the - endpoint to which communication needs end-to-end protection is - defined by the use case. + much partake in the security objectives to be achieved. The question + what are the pairs of endpoints between which the communication needs + 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 security, keying material needs to be established between the relevant nodes in the architecture. 4. Authentication and Authorization Server-side authorization solutions aim at protecting the access to items of interest, for instance hardware or software resources or data: They enable the resource owner to control who can access it and @@ -674,20 +672,24 @@ Note that actors are a concept to understand the security requirements for constrained devices. The architecture of an actual solution might differ as long as the security requirements that derive from the relationship between the identified actors are considered. Several actors might share a single device or even be combined in a single piece of software. Interfaces between actors may be realized as protocols or be internal to such a piece of 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 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 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 be Constrained Level Actors. C performs the following tasks: @@ -1309,29 +1311,34 @@ for the IP-based Internet of Things", 11th IEEE International Conference on Sensing, Communication, and 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] + Gerdes, S., "Authorization-Related Tasks in Constrained + Environments", draft-gerdes-ace-tasks-00 (work in + progress), September 2015. + [I-D.hardjono-oauth-umacore] Hardjono, T., Maler, E., Machulak, M., and D. Catalano, "User-Managed Access (UMA) Profile of OAuth 2.0", draft- hardjono-oauth-umacore-13 (work in progress), April 2015. [I-D.ietf-ace-usecases] Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. - Kumar, "ACE use cases", draft-ietf-ace-usecases-06 (work - in progress), September 2015. + Kumar, "ACE use cases", draft-ietf-ace-usecases-09 (work + in progress), October 2015. [I-D.koster-core-coap-pubsub] Koster, M., Keranen, A., and J. Jimenez, "Publish- Subscribe Broker for the Constrained Application Protocol (CoAP)", draft-koster-core-coap-pubsub-02 (work in progress), July 2015. [I-D.selander-ace-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "June 29, 2015", draft-selander-ace-object-security-02