--- 1/draft-ietf-ace-actors-04.txt 2017-03-06 15:13:08.910093779 -0800 +++ 2/draft-ietf-ace-actors-05.txt 2017-03-06 15:13:08.974095296 -0800 @@ -1,23 +1,23 @@ ACE Working Group S. Gerdes Internet-Draft Universitaet Bremen TZI Intended status: Informational L. Seitz -Expires: March 4, 2017 SICS Swedish ICT AB +Expires: September 7, 2017 SICS Swedish ICT AB G. Selander Ericsson C. Bormann, Ed. Universitaet Bremen TZI - August 31, 2016 + March 06, 2017 An architecture for authorization in constrained environments - draft-ietf-ace-actors-04 + draft-ietf-ace-actors-05 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,135 +30,139 @@ 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 4, 2017. + This Internet-Draft will expire on September 7, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of 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 . . . . . . . . 6 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6 - 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 + 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 9 2.3. Information Flows . . . . . . . . . . . . . . . . . . . . 11 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 12 3.1. End-to-End Security Objectives in Multi-Hop Scenarios . . 13 4. Authentication and Authorization . . . . . . . . . . . . . . 14 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16 - 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16 - 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 + 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 17 + 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 18 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 - 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 + 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 19 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 - 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 19 - 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 19 + 6.1.1. Cross Level Support Protocols . . . . . . . . . . . . 20 + 6.2. Less-Constrained Level Protocols . . . . . . . . . . . . 20 7. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 - 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 - 7.3. Communication Security . . . . . . . . . . . . . . . . . 21 + 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 21 + 7.3. Communication Security . . . . . . . . . . . . . . . . . 22 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 22 - 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 22 - 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 22 - 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 23 - 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 - 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 + 8. Assumptions and Requirements . . . . . . . . . . . . . . . . 23 + 8.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 23 + 8.2. Constrained Devices . . . . . . . . . . . . . . . . . . . 24 + 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 25 + 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 25 8.5. Client-side Authorization Information . . . . . . . . . . 25 - 8.6. Server-side Authorization Information . . . . . . . . . . 25 + 8.6. Server-side Authorization Information . . . . . . . . . . 26 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 - 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 - 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 + 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 27 + 8.9. Network Considerations . . . . . . . . . . . . . . . . . 27 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 - 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 28 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 12. Informative References . . . . . . . . . . . . . . . . . . . 29 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 11. Informative References . . . . . . . . . . . . . . . . . . . 30 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 32 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. + As described in [RFC7228], constrained nodes are small devices with + limited abilities which in many cases are made to fulfill a specific + simple task. They may 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, or may give rise to + particular deployment/management challenges. - Constrained nodes are expected to be integrated in all aspects of - everyday life and thus will be entrusted with vast amounts of data. - Without appropriate security mechanisms attackers might gain control - over things relevant to our lives. Authentication and authorization - mechanisms are therefore prerequisites for a secure Internet of - Things. + As components of the Internet of Things (IoT), constrained nodes are + expected to be integrated in all aspects of everyday life and thus + will be entrusted with vast amounts of data. Without appropriate + security mechanisms attackers might gain control over things relevant + to our lives. Authentication and authorization mechanisms are + therefore prerequisites for a secure Internet of Things. - Authorization is about who can do what to which objects. + Applications generally require some degree of authentication and + authorization, which gives rise to some complexity. Authorization is + about who can do what to which objects (see also [RFC4949]). Authentication specifically addresses the who, but is often specific to the authorization that is required (for example, it may be sufficient to authenticate the age of an actor, so no identifier is needed or even desired). Authentication often involves credentials, only some of which need to be long-lived and generic; others may be directed towards specific authorizations (but still possibly long- lived). Authorization then makes use of these credentials, as well as other information (such as the time of day). This means that the - application-induced complexity of authenticated authorization can - often be moved back and forth between these two aspects. + complexity of authenticated authorization can often be moved back and + forth between these two aspects. In some cases authentication and authorization can be addressed by static configuration provisioned during manufacturing or deployment by means of fixed trust anchors and static access control lists. This is particularly applicable to siloed, fixed-purpose deployments. However, as the need for flexible access to assets already deployed increases, the legitimate set of authorized entities as well as their specific privileges cannot be conclusively defined during deployment, without any need for change during the lifetime of the device. Moreover, several use cases illustrate the need for fine-grained access control policies, for which for instance a basic access control list concept may not be sufficiently powerful [RFC7744]. - The limitations of the constrained nodes ask for security mechanisms - which take the special characteristics of constrained environments - into account; not all constituents may be able to perform all - necessary tasks by themselves. In order to meet the security - requirements in constrained scenarios, the necessary tasks need to be - assigned to logical functional entities. + The limitations of the constrained nodes impose a need for security + mechanisms which take the special characteristics of constrained + environments into account; not all constituents may be able to + perform all necessary tasks by themselves. To put it the other way + round: the security mechanisms that protect constrained nodes must + remain effective and manageable despite the limitations imposed by + the constrained environment. - In order to be able to achieve complex security objectives between - actors some of which are hosted on simple ("constrained") devices, - some of the actors will make use of help from other, less constrained - actors. (This offloading is not specific to networks with - constrained nodes, but their constrainedness as the main motivation - is.) + Therefore, in order to be able to achieve complex security objectives + between actors some of which are hosted on simple ("constrained") + devices, some of the actors will make use of help from other, less + constrained actors. (This offloading is not specific to networks + with constrained nodes, but their constrainedness as the main + motivation 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 @@ -167,21 +171,21 @@ 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 + Readers are assumed to be familiar with the terms and concepts defined in [RFC4949], including "authentication", "authorization", "confidentiality", "(data) integrity", "message authentication code", and "verify". REST terms including "resource", "representation", etc. are to be understood as used in HTTP [RFC7231] and CoAP [RFC7252]; the latter also defines additional terms such as "endpoint". Terminology for constrained environments including "constrained device", "constrained-node network", "class 1", etc. is defined in @@ -255,20 +259,25 @@ o C in one endpoint requests to access R on a RS in another endpoint. o A priori, the endpoints do not necessarily have a pre-existing security relationship to each other. o Either of the endpoints, or both, may be constrained. 2.1. Elements of an Architecture + In its simplest expression, the architecture starts with a two-layer + model: the principal level (at which components are assumed to be + functionally unconstrained) and the constrained level (at which some + functional constraints are assumed to apply to the components). + Without loss of generality, we focus on the C functionality in one endpoint, which we therefore also call C, accessing the RS functionality in another endpoint, which we therefore also call RS. The constrained level and its security objectives are detailed in Section 5.1. -------------- -------------- | ------- | | ------- | | | C | ------ requests resource -----> | RS | | @@ -277,21 +286,21 @@ -------------- -------------- Figure 1: Constrained Level The authorization decisions at the endpoints are made on behalf of the principals that control the endpoints. To reuse OAuth and UMA terminology, the present document calls the principal that is controlling C the Requesting Party (RqP), and calls the principal that is controlling RS the Resource Owner (RO). Each principal makes authorization decisions (possibly encapsulating them into security - policies) which the endpoint it controls then enforces. + policies) which are then enforced by the endpoint it controls. The specific security objectives will vary, but for any specific version of this scenario will include one or more of: o Objectives of type 1: No entity not authorized by the RO has access to (or otherwise gains knowledge of) R. o Objectives of type 2: C is exchanging information with (sending a request to, accepting a response from) a resource only where it can ascertain that RqP has authorized the exchange with R. @@ -322,33 +331,34 @@ directly with the device because of a lack of user interfaces or displays, or may prefer the device to communicate autonomously. Moreover, constrained endpoints may need support with tasks requiring heavy processing, large memory or storage, or interfacing to humans, such as management of security policies defined by a principal. The principal, in turn, requires some agent maintaining the policies governing how its endpoints will interact. For these reasons, another level of nodes is introduced in the - architecture, the less-constrained level. Using OAuth terminology, - AS acts on behalf of the RO to control and support the RS in handling - access requests, employing a pre-existing security relationship with - RS. We complement this with CAS acting on behalf of RqP to control - and support the C in making resource requests and acting on the - responses received, employing a pre-existing security relationship - with C. To further relieve the constrained level, authorization (and - related authentication) mechanisms may be employed between CAS and AS - (Section 6.2). (Again, both CAS and AS are conceptual entities - controlled by their respective principals. Many of these entities, - often acting for different principals, can be combined into a single - server implementation; this of course requires proper segregation of - the control information provided by each principal.) + architecture, the less-constrained level (illustrated below in + Figure 3). Using OAuth terminology, AS acts on behalf of the RO to + control and support the RS in handling access requests, employing a + pre-existing security relationship with RS. We complement this with + CAS acting on behalf of RqP to control and support the C in making + resource requests and acting on the responses received, employing a + pre-existing security relationship with C. To further relieve the + constrained level, authorization (and related authentication) + mechanisms may be employed between CAS and AS (Section 6.2). (Again, + both CAS and AS are conceptual entities controlled by their + respective principals. Many of these entities, often acting for + different principals, can be combined into a single server + implementation; this of course requires proper segregation of the + control information provided by each principal.) ------- ------- | RqP | | RO | Principal Level ------- ------- | | controls controls | | V V -------- ------- | CAS | <- AuthN and AuthZ -> | AS | Less-Constrained Level @@ -368,24 +378,26 @@ Figure 3 shows all three levels considered in this document. Note that the vertical arrows point down to illustrate exerting control and providing support; this is complemented by information flows that often are bidirectional. Note also that not all entities need to be ready to communicate at any point in time; for instance, RqP may have provided enough information to CAS that CAS can autonomously negotiate access to RS with AS for C based on this information. 2.2. Architecture Variants - The elements of the architecture described above are architectural. - In a specific scenario, several elements can share a single device or - even be combined in a single piece of software. If C is located on a - more powerful device, it can be combined with CAS: + The elements of the architecture described above are indeed + architectural; that is, they are parts of a conceptual model, and may + be instantiated in various ways in practice. For example, in a given + scenario, several elements might share a single device or even be + combined in a single piece of software. If C is located on a more + powerful device, it can be combined with CAS: ------- -------- | RqP | | RO | Principal Level ------- -------- | | in charge of in charge of | | V V ------------ -------- | CAS + C | <- AuthN and AuthZ -> | AS | Less-Constrained Level @@ -522,42 +534,45 @@ establishing the keys used to protect these information flows. (Note that other aspects relevant to secure constrained node communication such as secure bootstrap or group communication are not specifically addressed by the present document.) 3. Security Objectives The security objectives that are addressed by an authorization solution include confidentiality and integrity. Additionally, - allowing only selected entities limits the burden on system - resources, thus helping to achieve availability. Misconfigured or - wrongly designed authorization solutions can result in availability - breaches (denial of service): Users might no longer be able to use - data and services as they are supposed to. + allowing only selected operations by selected entities limits the + burden on system resources, thus helping to achieve availability. + Misconfigured or wrongly designed authorization solutions can result + in availability breaches (denial of service): Users might no longer + be able to use data and services as they are supposed to. - Authentication mechanisms can achieve additional security objectives - such as accountability and third-party verifiability. These - additional objectives are not directly related to authorization and - thus are not in scope of this draft, but may nevertheless be + Authentication mechanisms can help achieve additional security + objectives such as accountability and third-party verifiability. + These additional objectives are not directly related to authorization + and thus are not in scope of this draft, but may nevertheless be relevant. Accountability and third-party verifiability may require authentication on a device level, if it is necessary to determine which device performed an action. In other cases it may be more important to find out who is responsible for the device's actions. - See also Section 4 for more discussion about authentication and - authorization. + (The ensuing requirements for logging, auditability, and the related + integrity requirements are very relevant for constrained devices as + well, but outside the scope of this document.) See also Section 4 + for more discussion about authentication and authorization. The security objectives and their relative importance differ for the various constrained environment applications and use cases [RFC7744]. - In many cases, one participating party has different security - objectives than another. To achieve a security objective of one + The architecture is based on the observation that different parties + may have different security objectives. There may also be a + "collaborative" dimension: 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 in Multi-Hop Scenarios @@ -566,22 +581,23 @@ 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 beyond a single client-server exchange. + fulfill the security objectives of the endpoints, it is the endpoints + that will need to 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. 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 specific 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 @@ -609,89 +625,103 @@ To determine if an entity is authorized to access a resource, an authentication mechanism is needed. According to the Internet Security Glossary [RFC4949], authentication is "the process of verifying a claim that a system entity or system resource has a certain attribute value." Examples for attribute values are the ID of a device, the type of the device or the name of its owner. The security objectives the authorization mechanism aims at can only be achieved if the authentication and the authorization mechanism work together correctly. We speak of authenticated authorization to - refer to the required synthesis of mechanism for authentication and + refer to the required synthesis of mechanisms for authentication and authorization. Where used for authorization, the set of authenticated attributes must be meaningful for this purpose, i.e., authorization decisions must be possible based on these attributes. If the authorization policy assigns permissions to an individual entity, the set of authenticated attributes must be suitable to uniquely identify this entity. - In scenarios where devices are communicating autonomously there is - often less need to uniquely identify an individual device: For a - principal, the fact that a device belongs to a certain company or - that it has a specific type (such as a light bulb) or location may be - more important than that it has a unique identifier. + In other scenarios, there is often less need to uniquely identify an + individual device: For a principal, the fact that a device belongs to + a certain company or that it has a specific type (such as a light + bulb) or location may be more important than that it has a unique + identifier. (As a special case for the authorization of read access to a resource, RS may simply make an encrypted representation available to anyone [OSCAR]. In this case, controlling read access to that resource can be reduced to controlling read access to the key; - partially removing access also requires a timely update of the key - for RS and all participants still authorized.) - + partially removing future access also requires a timely update of the + key for RS and all participants still authorized.) Principals (RqP and RO) need to decide about the required level of granularity for the authorization. For example, we distinguish device authorization from owner authorization, and flat authorization from unrestricted authorization. In the first case different access permissions are granted to individual devices while in the second case individual owners are authorized. If flat authorization is used, all authenticated entities are implicitly authorized and have the same access permissions. Unrestricted authorization for an item of interest means that no authorization mechanism is used for accessing this resource (not even by authentication) and all entities are able to access the item as they see fit (note that an authorization mechanism may still be used to arrive at the decision to employ unrestricted authorization). + +-----------------+-------------------------------------------------+ + | Authorization | Authorization is contingent on: | + | granularity | | + +-----------------+-------------------------------------------------+ + | device | authentication of specific device | + | | | + | owner | (authenticated) authorization by owner | + | | | + | flat | (any) authentication | + | | | + | unrestricted | (unrestricted access; access always authorized) | + +-----------------+-------------------------------------------------+ + + Table 1: Some granularity levels for authorization + More fine-grained authorization does not necessarily provide more security but can be more flexible. Principals need to consider that an entity should only be granted the permissions it really needs (principle of least privilege), to ensure the confidentiality and integrity of resources. Client-side authorization solutions aim at protecting the client from disclosing information to or ingesting information from resource servers RqP does not want it to interact with in the given way. Again, flat authorization (the server can be authenticated) may be sufficient, or more fine-grained authorization may be required. The client-side authorization also pertains to the level of protection required for the exchanges with the server (e.g., confidentiality). In the browser web, client-side authorization is often left to the human user; a constrained client may not have that available all the time but still needs to implement the wishes of the principal controlling it, the RqP. - For all cases where an authorization solution is needed (all but + For the cases where an authorization solution is needed (all but unrestricted authorization), the enforcing party needs to be able to authenticate the party that is to be authorized. Authentication is therefore required for messages that contain (or otherwise update) representations of an accessed item. More precisely: The enforcing party needs to make sure that the receiver of a message containing a representation is authorized to receive it, both in the case of a client sending a representation to a server and vice versa. In addition, it needs to ensure that the actual sender of a message containing a representation is indeed the one authorized to send this message, again for both the client-to-server and server-to-client case. To achieve this, integrity protection of these messages is - required: Authenticity cannot be assured if it is possible for an - attacker to modify the message during transmission. + required: Authenticity of the message cannot be assured if it is + possible for an attacker to modify it during transmission. In some cases, only one side (client or server side) requires the integrity and / or confidentiality of a resource value. Principals may decide to omit authentication (unrestricted authorization), or use flat authorization (just employing an authentication mechanism). However, as indicated in Section 3, the security objectives of both sides must be considered, which can often only be achieved when the other side can be relied on to perform some security service. 5. Actors and their Tasks @@ -960,21 +989,21 @@ o Session-based security at transport layer such as DTLS [RFC6347] offers security, including integrity and confidentiality protection, for the whole application layer exchange. However, DTLS may not provide end-to-end security over multiple hops. Another problem with DTLS is the cost of the handshake protocol, which may be too expensive for constrained devices especially in terms of memory and power consumption for message transmissions. o An alternative is object security at application layer, for - instance using [I-D.selander-ace-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 a more flexible communication model such as publish/subscribe (compare e.g. CoRE Mirror Server [I-D.koster-core-coap-pubsub]). A problem with object security is that it can not provide confidentiality for the message headers. o Hybrid solutions using both session-based and object security are also possible. An example of a hybrid is where authorization information and cryptographic keys are provided by AS in the format of secure data objects, but where the resource access is @@ -1335,31 +1365,21 @@ 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. -11. Acknowledgements - - The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel - Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, - Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis - and Erik Wahlstroem for contributing to the discussion, giving - helpful input and commenting on previous forms of this draft. The - authors would also like to specifically acknowledge input provided by - Hummen and others [HUM14delegation]. - -12. Informative References +11. Informative References [HUM14delegation] Hummen, R., Shafagh, H., Raza, S., Voigt, T., and K. Wehrle, "Delegation-based Authentication and Authorization 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 @@ -1371,31 +1391,31 @@ 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-14 (work in progress), January 2016. + [I-D.ietf-core-object-security] + Selander, G., Mattsson, J., Palombini, F., and L. Seitz, + "Object Security of CoAP (OSCOAP)", draft-ietf-core- + object-security-01 (work in progress), December 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-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-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., @@ -1445,20 +1465,32 @@ 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, . +Acknowledgements + + The authors would like to thank Olaf Bergmann, Robert Cragie, Samuel + Erdtman, Klaus Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, + Mohit Sethi, Abhinav Somaraju, Hannes Tschofenig, Vlasios Tsiatsis + and Erik Wahlstroem for contributing to the discussion, giving + helpful input and commenting on previous forms of this draft. The + authors would also like to specifically acknowledge input provided by + Hummen and others [HUM14delegation]. Robin Wilton provided extensive + editorial comments that were the basis for significant improvements + of the text. + Authors' Addresses Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org