--- 1/draft-ietf-ace-actors-02.txt 2016-03-01 15:17:28.304840244 -0800 +++ 2/draft-ietf-ace-actors-03.txt 2016-03-01 15:17:28.404842749 -0800 @@ -1,23 +1,23 @@ ACE Working Group S. Gerdes Internet-Draft Universitaet Bremen TZI Intended status: Informational L. Seitz -Expires: April 21, 2016 SICS Swedish ICT AB +Expires: September 2, 2016 SICS Swedish ICT AB G. Selander Ericsson C. Bormann, Ed. Universitaet Bremen TZI - October 19, 2015 + March 01, 2016 An architecture for authorization in constrained environments - draft-ietf-ace-actors-02 + draft-ietf-ace-actors-03 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,75 +30,75 @@ 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 April 21, 2016. + This Internet-Draft will expire on September 2, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 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 . . . . . . . . 5 - 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 5 + 2. Architecture and High-level Problem Statement . . . . . . . . 6 + 2.1. Elements of an Architecture . . . . . . . . . . . . . . . 6 2.2. Architecture Variants . . . . . . . . . . . . . . . . . . 8 - 2.3. Problem statement . . . . . . . . . . . . . . . . . . . . 11 + 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 . . . . . . . . . . . . . . 13 - 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 15 + 4. Authentication and Authorization . . . . . . . . . . . . . . 14 + 5. Actors and their Tasks . . . . . . . . . . . . . . . . . . . 16 5.1. Constrained Level Actors . . . . . . . . . . . . . . . . 16 5.2. Principal Level Actors . . . . . . . . . . . . . . . . . 17 - 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 17 + 5.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 18 6. Kinds of Protocols . . . . . . . . . . . . . . . . . . . . . 18 - 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 18 + 6.1. Constrained Level Protocols . . . . . . . . . . . . . . . 19 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. Elements of a Solution . . . . . . . . . . . . . . . . . . . 20 + 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Authentication . . . . . . . . . . . . . . . . . . . . . 20 7.3. Communication Security . . . . . . . . . . . . . . . . . 21 - 7.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . 21 + 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.5. Client-side Authorization Information . . . . . . . . . . 24 + 8.5. Client-side Authorization Information . . . . . . . . . . 25 8.6. Server-side Authorization Information . . . . . . . . . . 25 - 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 25 + 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 - 8.10. Legacy 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 . . . . . . . . . . . . . . . . . . . . 28 + 9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 29 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- @@ -130,21 +130,21 @@ 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. + 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. In order to be able to achieve complex security objectives between actors some of which are hosted on simple ("constrained") devices, @@ -179,101 +179,114 @@ also defines additional terms such as "endpoint". Terminology for constrained environments including "constrained device", "constrained-node network", "class 1", etc. is defined in [RFC7228]. In addition, this document uses the following terminology: Resource (R): an item of interest which is represented through an interface. It might contain sensor or actuator values or other - information. + information. (Intended to coincide with the definitions of + [RFC7252] and [RFC7231].) Constrained node: a constrained device in the sense of [RFC7228]. Actor: A logical functional entity that performs one or more tasks. Multiple actors may be present within a single device or a single piece of software. Resource Server (RS): An entity which hosts and represents a - Resource. + Resource. (Used here to discuss the server that provides a + resource that is the end, not the means, of the authenticated + authorization process - i.e., not CAS or AS.) - Client (C): An entity which attempts to access a resource on an RS. + Client (C): An entity which attempts to access a resource on a RS. + (Used to discuss the client whose access to a resource is the end, + not the means, of the authenticated authorization process.) Principal: (Used in its English sense here, and specifically as:) An individual that is either RqP or RO or both. Resource Owner (RO): The principal that is in charge of the resource and controls its access permissions. Requesting Party (RqP): The principal that is in charge of the Client and controls the requests a Client makes and its acceptance of responses. Authorization Server (AS): An entity that prepares and endorses authentication and authorization data for a Resource Server. Client Authorization Server (CAS): An entity that prepares and endorses authentication and authorization data for a Client. - Authenticated Authorization: A synthesis of mechanisms for - authentication and authorization. + Authorization Manager: An entity that prepares and endorses + authentication and authorization data for a constrained node. + Used in constructions such as "a constrained node's authorization + manager" to denote AS for RS and CAS for C. + + Authenticated Authorization: The confluence of mechanisms for + authentication and authorization, ensuring that authorization is + applied to and made available for authenticated entities and that + entities providing authentication services are authorized to do so + for the specific authorization process at hand. Note that other authorization architectures such as OAuth [RFC6749] or UMA [I-D.hardjono-oauth-umacore] focus on the authorization problems on the RS side, in particular what accesses to resources the RS is to allow. In this document the term authorization includes this aspect, but is also used for the client-side aspect of - authorization, i.e., more generally to describe allowed interactions - with other endpoints. + authorization, i.e., more generally allowing RqPs to decide what + interactions clients may perform with other endpoints. 2. Architecture and High-level Problem Statement -2.1. Elements of an Architecture - This document deals with how to control and protect resource-based interaction between potentially constrained endpoints. The following - setting is assumed: + setting is assumed as a high-level problem statement: o An endpoint may host functionality of one or more actors. 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 + 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 | | | ------- <----- provides resource ------ ------- | | Endpoint | | Endpoint | -------------- -------------- 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 C's controlling principal the - Requesting Party (RqP), and calls RS's controlling principal the - Resource Owner (RO). Each principal makes authorization decisions - (possibly encapsulating them into security policies) which the - endpoint it controls then enforces. + 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. 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. @@ -291,26 +304,25 @@ | | in charge of in charge of | | V V ------- ------- | C | -- requests resource --> | RS | Constrained Level ------- <-- provides resource-- ------- Figure 2: Constrained Level and Principal Level - The use cases defined in [I-D.ietf-ace-usecases] demonstrate that - constrained devices are often used for scenarios where their - principals are not present at the time of the communication, are not - able to communicate directly with the device because of a lack of - user interfaces or displays, or may prefer the device to communicate - autonomously. + The use cases defined in [RFC7744] demonstrate that constrained + devices are often used for scenarios where their principals are not + present at the time of the communication, are not able to communicate + 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 @@ -429,21 +442,21 @@ and authorization and authorization support support / \ V V ------- ------- | C | -- requests resource --> | RS | Constrained Level ------- <-- provides resource -- ------- Figure 6: CAS combined with AS -2.3. Problem statement +2.3. Information Flows We now formulate the problem statement in terms of the information flows the architecture focuses on. 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 @@ -474,60 +487,64 @@ 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 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: + In terms of the elements of the architecture laid out above, this + document's problem statement for authorization in constrained + environments can then 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 interaction, potentially end-to-end through intermediary nodes. o The mechanism for transferring control information needs to be secured, potentially end-to-end through intermediary nodes. Pre- established keying material may need to be employed for 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: Users might no longer be able to use data and services as - they are supposed to. + 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 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 security objectives and their relative importance differ for the - various constrained environment applications and use cases - [I-D.ietf-ace-usecases]. + 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 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. @@ -546,22 +563,22 @@ 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. 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 use case. Two examples of intermediary nodes executing security - functionality: + 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 (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 @@ -625,42 +642,54 @@ 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). 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 - Unrestricted Authorization), the enforcing party needs to be able to + 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. 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 - the other side can be relied on to perform some security service. + other side can be relied on to perform some security service. 5. Actors and their Tasks This and the following section look at the resulting architecture from two different perspectives: This section provides a more detailed description of the various "actors" in the architecture, the logical functional entities performing the tasks required. The following section then will focus on the protocols run between these functional entities. @@ -689,40 +718,46 @@ 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: o Communicate in a secure way (provide for confidentiality and integrity of messages), including access requests. - o Validate that an entity is an authorized server for R. + o Validate that the RqP ("client-side") authorization information + allows C to communicate with RS as a server for R (i.e., from C's + point of view, RS is authorized as a server for the specific + access to R). RS performs the following tasks: o Communicate in a secure way (provide for confidentiality and integrity of messages), including responses to access requests. - o Validate the authorization of the requester to access the - requested resource as requested. + o Validate that the RO ("server-side") authorization information + allows RS to grant C access to the requested resource as requested + (i.e., from RS' point of view, C is authorized as a client for the + specific access to R). R is an item of interest such as a sensor or actuator value. R is considered to be part of RS and not a separate actor. The device on - which RS is located might contain several resources of different ROs. - For simplicity of exposition, these resources are described as if - they had separate RS. + which RS is located might contain several resources controlled by + different ROs. For simplicity of exposition, these resources are + described as if they had separate RS. As C and RS do not necessarily know each other they might belong to different security domains. (See Figure 8.) + ------- -------- | C | -- requests resource ---> | RS | Constrained Level ------- <-- provides resource--- -------- Figure 8: Constrained Level Actors 5.2. Principal Level Actors Our objective is that C and RS are under control of principals in the physical world, the Requesting Party (RqP) and the Resource Owner @@ -882,21 +917,21 @@ 7.2. Authentication The following problems need to be addressed, when considering authentication: 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 to authenticate each other, both to perform + 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 implicit, for example by encrypting the resource representation the RS only providing access to those who possess the key to decrypt. @@ -949,24 +984,24 @@ consume considerably more time/battery for asymmetric operations. On the other hand asymmetric cryptography has benefits such as in terms of deployment. Key Establishment How are the corresponding cryptographic keys established? Considering Section 7.1 there must be a mapping between these keys and the authorization information, at least in the sense that AS must be able to specify a unique client identifier which RS can verify (using an associated key). One of the use cases of - [I-D.ietf-ace-usecases] describes spontaneous change of access - policies - such as giving a hitherto unknown client the right to - temporarily unlock your house door. In this case C is not - previously known to RS and a key must be provisioned by AS. + [RFC7744] describes spontaneous change of access policies - such + as giving a hitherto unknown client the right to temporarily + unlock your house door. In this case C is not previously known to + RS and a key must be provisioned by AS. Revocation and Expiration How are keys replaced and how is a key that has been compromised revoked in a manner that reaches all affected parties, also keeping in mind scenarios with intermittent connectivity? 8. Assumptions and Requirements In this section we list a set of candidate assumptions and requirements to make the problem description in the previous sections @@ -1023,21 +1057,23 @@ o CAS and AS are not assumed to be constrained devices. o All devices under consideration can process symmetric cryptography without incurring an excessive performance penalty. * We assume the use of a standardized symmetric key algorithm, such as AES. * Except for the most constrained devices we assume the use of a - standardized cryptographic hash function such as SHA-256. + standardized cryptographic hash function such as SHA-256 (which + can be used with the HMAC construction for integrity + protection). o Public key cryptography requires additional resources (such as RAM, ROM, power, specialized hardware). o A DTLS handshake involves significant computation, communication, 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. @@ -1046,21 +1082,21 @@ 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). 8.3. Authentication o RS needs to authenticate AS to ensure that the authorization information and related data comes from the correct source. - o Similary, 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 source. o Depending on use case and authorization requirements, C, RS, CAS, or AS may need to authenticate messages from each other. 8.4. Server-side Authorization o RS enforces authorization for access to a resource based on credentials presented by C, the requested resource, the REST @@ -1118,33 +1154,33 @@ i.e. information located at a particular URI, accessed with RESTful methods, and the access being subject to the same authorization mechanics. AS may have special privileges when requesting access to the authorization policy resources on RS. o There may be mechanisms for C to look up the AS which provides authorization information about a particular resource. 8.7. Resource Access - o Resources are accessed in a RESTful manner using GET, PUT, POST, - DELETE. + o Resources are accessed in a RESTful manner using methods such as + GET, PUT, POST, DELETE. o By default, the resource request needs to be integrity protected and may be encrypted end-to-end from C to RS. It needs to be possible for RS to detect a replayed request. o By default, the response to a request needs to be integrity - protected and encrypted end-to-end from RS to C. It needs to be - possible for C to detect a replayed response. + protected and may be encrypted end-to-end from RS to C. It needs + to be possible for C to detect a replayed response. o RS needs to be able to verify that the request comes from an - authorized client + authorized client. o C needs to be able to verify that the response to a request comes from the intended RS. o There may be resources whose access need not be protected (e.g. for discovery of the responsible AS). 8.8. Keys and Cipher Suites o A constrained node and its authorization manager (i.e., RS and AS, @@ -1288,27 +1324,27 @@ 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, Klaus - Hartke, Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi, - 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]. + 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 [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. @@ -1319,37 +1355,33 @@ 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-09 (work - in progress), October 2015. + 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-02 (work in - progress), July 2015. + (CoAP)", draft-koster-core-coap-pubsub-04 (work in + progress), November 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 - (work in progress), June 2015. + "Object Security of CoAP (OSCOAP)", draft-selander-ace- + object-security-03 (work in progress), October 2015. [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. [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, @@ -1390,22 +1422,27 @@ [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, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ RFC7252, June 2014, . -Authors' Addresses + [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, + . +Authors' Addresses Stefanie Gerdes Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63906 Email: gerdes@tzi.org Ludwig Seitz