--- 1/draft-ietf-ace-actors-03.txt 2016-09-03 14:15:58.021034782 -0700 +++ 2/draft-ietf-ace-actors-04.txt 2016-09-03 14:15:58.085036258 -0700 @@ -1,23 +1,23 @@ ACE Working Group S. Gerdes Internet-Draft Universitaet Bremen TZI Intended status: Informational L. Seitz -Expires: September 2, 2016 SICS Swedish ICT AB +Expires: March 4, 2017 SICS Swedish ICT AB G. Selander Ericsson C. Bormann, Ed. Universitaet Bremen TZI - March 01, 2016 + August 31, 2016 An architecture for authorization in constrained environments - draft-ietf-ace-actors-03 + draft-ietf-ace-actors-04 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 September 2, 2016. + This Internet-Draft will expire on March 4, 2017. Copyright Notice Copyright (c) 2016 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 @@ -84,25 +84,25 @@ 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 8.5. Client-side Authorization Information . . . . . . . . . . 25 8.6. Server-side Authorization Information . . . . . . . . . . 25 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 - 9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 29 + 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 12. Informative References . . . . . . . . . . . . . . . . . . . 29 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 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 cases do not have user interfaces and displays. Due to these constraints, commonly used security protocols are not always easily applicable. @@ -154,20 +154,25 @@ is.) We therefore group the logical functional entities by whether they can be assigned to a constrained device ("constrained level") or need higher function platforms ("less-constrained level"); the latter does not necessarily mean high-function, "server" or "cloud" platforms. Note that assigning a logical functional entity to the constrained level does not mean that the specific implementation needs to be constrained, only that it _can_ be. + The description assumes that some form of setup (aspects of which are + often called provisioning and/or commissioning) has already been + performed and at least some initial security relationships important + for making the system operational have already been established. + This document provides some terminology, and identifies the elements an architecture needs to address, representing the relationships between the logical functional entities involved; on this basis, a problem description for authentication and authorization in constrained-node networks is provided. 1.1. Terminology Readers are required to be familiar with the terms and concepts defined in [RFC4949], including "authentication", "authorization", @@ -445,21 +450,26 @@ V V ------- ------- | C | -- requests resource --> | RS | Constrained Level ------- <-- provides resource -- ------- Figure 6: CAS combined with AS 2.3. Information Flows We now formulate the problem statement in terms of the information - flows the architecture focuses on. + flows the architecture focuses on. (While the previous section + discusses the architecture in terms of abstract devices and their + varying roles, the actual protocols being standardized define those + information flows and the messages embodying them: "RESTful + architectures focus on defining interfaces and not components" + ([REST], p. 116).) 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 @@ -923,21 +933,21 @@ o RS needs to authenticate AS, and C needs to authenticate CAS, to ensure that the authorization information and related data comes from the correct source. o CAS and AS may need to authenticate each other, both to perform the required business logic and to ensure that CAS gets security information related to the resources from the right source. o In some use cases RS needs to authenticate some property of C, in order to map it to the relevant authorization information. In - other use cases, authentication and authorization of C may be + other applications, authentication and authorization of C may be implicit, for example by encrypting the resource representation the RS only providing access to those who possess the key to decrypt. o C may need to authenticate RS, in order to ensure that it is interacting with the right resources. Alternatively C may just verify the integrity of a received resource representation. o CAS and AS need to authenticate their communication partner (C or RS), in order to ensure it serves the correct device. @@ -1075,21 +1085,21 @@ and memory overheads in the context of constrained devices. * The RAM requirements of DTLS handshakes with public key cryptography are prohibitive for certain constrained devices. * Certificate-based DTLS handshakes require significant volumes of communication, RAM (message buffers) and computation. o A solution will need to consider support for a simple scheme for 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 9.2). 8.3. Authentication o RS needs to authenticate AS to ensure that the authorization information and related data comes from the correct source. o Similarly, C needs to authenticate CAS to ensure that the authorization information and related data comes from the correct source. @@ -1292,40 +1302,43 @@ 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 protect assets which are exposed during a physical attack. In other words, either an attacker does not have physical access to the sensor or actuator device, or if it has, the attack shall only have effect during the period of physical attack, and shall be limited in extent to the physical control the attacker exerts (e.g., must not affect the security of other devices.) -9.2. Time Measurements +9.2. Clocks and Time Measurements - Measuring 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. + 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 or revocation of authorization decisions or to distinguish new authorization decisions from old. For certain categories of devices we can assume that there is an internal clock which is sufficiently accurate to handle the time - measurement requirements. If RS can connect directly to AS it could - get updated in terms of time as well as revocation information. + measurement requirements. If RS can connect directly to AS, this + relationship can be used to update RS in terms of time, removing some + uncertainty, as well as to directly provide revocation information, + removing authorizations that are no longer desired. - If RS continuously measures time but can't connect to AS or other - trusted source, time drift may have to be accepted and it may not be - able to manage revocation. However, it may still be able to handle - short lived access rights within some margins, by measuring the time - since arrival of authorization information or request. + 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 + be harder to manage revocation. However, it may still be able to + handle short lived access rights within some margins, by measuring + the time since arrival of authorization information or request. Some categories of devices in scope may be unable measure time with any accuracy (e.g. because of sleep cycles). This category of devices is not suitable for the use cases which require measuring validity of assertions and authorizations in terms of absolute time. 10. IANA Considerations This document has no actions for IANA. @@ -1361,88 +1374,93 @@ [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-14 (work in progress), January 2016. [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-04 (work in - progress), November 2015. + (CoAP)", draft-koster-core-coap-pubsub-05 (work in + progress), July 2016. [I-D.selander-ace-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-selander-ace- - object-security-03 (work in progress), October 2015. + object-security-05 (work in progress), July 2016. [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., Damon, L., and R. Guizzetti, "OSCAR: Object Security Architecture for the Internet of Things", CoRR vol. abs/1404.7799, 2014. + [REST] Fielding, R. and R. Taylor, "Principled design of the + modern Web architecture", ACM Trans. Inter. Tech. Vol. + 2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002. + [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and - D. Spence, "AAA Authorization Framework", RFC 2904, DOI - 10.17487/RFC2904, August 2000, + D. Spence, "AAA Authorization Framework", RFC 2904, + DOI 10.17487/RFC2904, August 2000, . [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, . - [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI - 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ - RFC5246, August 2008, + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for - Constrained-Node Networks", RFC 7228, DOI 10.17487/ - RFC7228, May 2014, + Constrained-Node Networks", RFC 7228, + DOI 10.17487/RFC7228, May 2014, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Message Syntax and Routing", RFC - 7230, DOI 10.17487/RFC7230, June 2014, + Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer - Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI - 10.17487/RFC7231, June 2014, + Protocol (HTTP/1.1): Semantics and Content", RFC 7231, + DOI 10.17487/RFC7231, June 2014, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained - Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ - RFC7252, June 2014, + Application Protocol (CoAP)", RFC 7252, + DOI 10.17487/RFC7252, June 2014, . [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, + Authorization in Constrained Environments", RFC 7744, + DOI 10.17487/RFC7744, January 2016, . Authors' Addresses + Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org Ludwig Seitz