CoRE Working Group G. Selander Internet-Draft M. Sethi Intended Status: Standards Track Ericsson Expires: January 6, 2014 L. Seitz SICS Swedish ICT July 5, 2013 Access Control Framework for Constrained Environments draft-selander-core-access-control-00 Abstract The Constrained Application Protocol (CoAP) is a light-weight web transfer protocol designed to be used in constrained nodes and constrained networks. Communication security support for CoAP, including authentication, encryption, integrity protection, is well understood and a DTLS binding for CoAP is specified, but authorization and access control are not described in detail. This document describes a generic and dynamic access control framework suitable for constrained environments using CoAP. The framework builds on standards and well known paradigms for access control, externalizing authorization decision making to unconstrained nodes while performing authorization decision enforcement and verification of local conditions in constrained devices. In addition, this document provides alternative or complementary key management to the CoAP security modes. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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". The list of current Internet-Drafts can be accessed at Expires January 6, 2014 [Page 1] INTERNET DRAFT July 5, 2013 http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements, rationale and outline . . . . . . . . . . . . . 5 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Outline of Access Control Framework . . . . . . . . . . . . 8 3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Resource Owner . . . . . . . . . . . . . . . . . . . . . . 10 3.2 Authorization Server . . . . . . . . . . . . . . . . . . . 10 3.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Resource Server . . . . . . . . . . . . . . . . . . . . . . 11 4. Assertion profiles . . . . . . . . . . . . . . . . . . . . . . 12 4.1 Assertion requirements . . . . . . . . . . . . . . . . . . 12 4.2 Assertion wrapping . . . . . . . . . . . . . . . . . . . . 13 4.3 Assertion transport . . . . . . . . . . . . . . . . . . . . 13 5. Message protection profiles . . . . . . . . . . . . . . . . . . 14 5.1 Communication security profile . . . . . . . . . . . . . . 14 5.1.1 Assertion caching in resource server (informational) . . 15 5.2 Object security profile . . . . . . . . . . . . . . . . . . 16 5.2.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2 PUT/POST . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2.3 DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.4 Assertion replay protection (informational) . . . . . . 18 Expires January 6, 2014 [Page 2] INTERNET DRAFT July 5, 2013 6. Intermediary processing and notifications . . . . . . . . . . . 19 6.1 Intermediary nodes . . . . . . . . . . . . . . . . . . . . . 19 6.2 Mirror Server . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 Observe . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Trust management . . . . . . . . . . . . . . . . . . . . . . . 20 7.1 Access Control Lists . . . . . . . . . . . . . . . . . . . 21 7.2 Key provisioning schemes . . . . . . . . . . . . . . . . . 23 7.2.1 ACF PK Scheme . . . . . . . . . . . . . . . . . . . . . 23 7.2.2 ACF SSK Scheme . . . . . . . . . . . . . . . . . . . . 24 7.3 Key provisioning examples . . . . . . . . . . . . . . . . . 25 7.3.1 The authorization server as certification authority . . 26 7.3.2 The authorization server for configuration of raw public keys . . . . . . . . . . . . . . . . . . . . . . 26 7.3.3 The assertion as an authentication token . . . . . . . . 26 7.3.4 Using the assertion to transport the nonce . . . . . . . 27 7.3.5 TLS extension for transport of nonce . . . . . . . . . . 27 8. ACF Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1 Assertion Profile: Compact SAML-XACML . . . . . . . . . . . 27 8.2 Communication Security Profile: DTLS PSK with Bind Key . . 31 8.3 Object Security Profile: JWE-protected CoAP payload . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 11.1 Normative References . . . . . . . . . . . . . . . . . . . 35 11.2 Informative References . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Expires January 6, 2014 [Page 3] INTERNET DRAFT July 5, 2013 1. Introduction The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a light-weight web transfer protocol suitable for applications in embedded devices used in services such as smart energy, smart home, building automation, remote patient monitoring etc. Due to the nature of the these use cases including critical, unattended infrastructure and the personal sphere, security and privacy are critical components. CoAP message exchanges can be protected with different security protocols. The CoAP specification defines a DTLS binding for CoAP, which provides communication security services including authentication, encryption, integrity protection and replay protection. Authorization and access control - i.e. controlling who has access to what - is addressed with access control lists, which are assumed to have been provisioned to the devices and which contain e.g. lists of identifiers that may start DTLS sessions with the devices. There are some limitations with this approach: 1. By restricting the scope of access control to the granularity of identifiers with "root" access, it is not possible to give different privileges to different entities that are allowed to access the same device. For example, it may be desirable to give some clients the right to GET resources but others the right to POST or PUT resources to the same device; or to give the same client different access rights for different resources on the same device. 2. Furthermore, in certain use cases the granularity of GET/PUT/POST/DELETE is not sufficient to specify the relevant access restrictions. For example, the access policy may depend on local conditions of the device such as: date and time, proximity, geo- location, detected effort (press 3 times) or other aspects of the current state of the device. 3. Another limitation is that it is neither defined how to change the access privileges except by means of re-provisioning, nor how such changes would be authorized. The use of more flexible access control also enables more advanced business settings, for example: outsourcing of operations of sensor networks, data harvesting in leased networks, etc. All these aspects could in principle be addressed with customized Expires January 6, 2014 [Page 4] INTERNET DRAFT July 5, 2013 access control lists, but if access control should be standardized for CoAP, it seems more appropriate to use of existing access control standards instead of re-inventing the wheel for a particular protocol or use case. This document proposes a framework that allows fine-grained and flexible standard-compatible access control applicable to a generic setting including use cases with constrained devices such e.g. class 1 devices [I-D.ietf-lwig-terminology]. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Certain security-related terms are to be understood in the sense defined in [RFC4949]. These terms include, but are not limited to, "authentication", "authorization", "access control", "confidentiality", "credential", "encryption", "sign", "signature", "data integrity", and "verify". Terminology for constrained environments is defined in [I-D.ietf- lwig-terminology]. These terms include, but are not limited to, "constrained device", "constrained network", and "device class". 2. Requirements, rationale and outline This section gives an overview of the requirements that form the basis for the proposed Access Control Framework, as well as the rationale behind it, and furthermore it gives a rough outline of how the framework is applied. 2.1 Requirements The Access Control Framework SHALL support - access control in a constrained environment with constrained devices or networks, in particular, -- no additional messages SHOULD be sent or received by a constrained device exclusively for performing access control. Expires January 6, 2014 [Page 5] INTERNET DRAFT July 5, 2013 - access control applicable to a variety of use cases and access purposes, in particular -- differentiated access rights for different requesting entities, -- access control at least at the granularity of RESTful resources, -- access policies based on local conditions (e.g. state of device, time, position), - changes to access policies without re-provisioning, and - state-of-the-art security (in particular access control) standards and best practices (in particular end-to-end security between resource and authorized client). The Access Control Framework SHALL be compatible with a large variety of client-server authentication methods, message protection mechanisms (communication/object security), device key management procedures and trust anchors (secret keys, raw public keys, certificates). 2.2 Rationale Consider the main setting in focus where a CoAP client wants to access a resource hosted on a CoAP server, which is potentially a constrained device, and where the access rights should be determined by the owner of the resource. To comply with requirements on generic applicability, granular, and standardized access control, we need to be able to support some fairly general and rich access control policy language, e.g. XACML [XACML]. Managing and evaluating XACML or similar policies is too heavyweight for constrained devices. As a consequence we propose to externalize the main authorization decision to a less constrained node called the Authorization Server, acting on behalf of the resource owner. On the other hand, access control enforcement SHOULD be performed in a trusted environment associated to the resource and as close to the resource as possible, in order to provide end-to-end security between resource and authorized client. Moreover, verifications of local conditions SHOULD be performed in conjunction with accessing the resource for the following reasons: Expires January 6, 2014 [Page 6] INTERNET DRAFT July 5, 2013 - Transporting information about local conditions in the resource server to an authorization server for each policy decision (or on a regular basis) introduces delays and/or adds additional messages exclusively for the purpose of performing access control. - Local conditions may have changed at the time of enforcement. We therefore target enforcement and local decisions to take place in the constrained device hosting the resource, or in a proxy-type device offloading a severely constrained device hosting the resource. We express local conditions as constraints under which an externally granted authorization decision is valid, and which are verified at the time and location of enforcement. For example if using XACML, such constraints can be expressed by Obligations. In order to convey the authorization decisions (including local decision constraints) from the authorization server to the device where access control is enforced we use authorization assertions, which are digitally signed data objects containing authorization information. Examples of authorization assertions are SAML XACML authorization decision assertions [SAML-XACML] and OAuth 2.0 MAC tokens [I-D.ietf-oauth-v2-http-mac]. The assertions need to be lightweight so that constrained devices can parse and enforce authorization decisions. However, as this framework is targeting a variety of different constrained devices, protection mechanisms and use cases, we allow different assertion formats just as we must support different authentication methods and message protection mechanisms. In order to encompass these different setups, this framework requires the specification of accompanying "profile", the contents of which are defined later in this document. NOTES 1. The authorization server must be trusted by all involved parties, in particular by the resource server (and the resource owner). We assume that this trust relationship is manifested through trusted keys established a priori in the resource server and the authorization server (Section 7). 2. The existence of such a trust relationship, once introduced to support authorization and access control, can be utilized to optimize key establishment, authentication and message protection between the Expires January 6, 2014 [Page 7] INTERNET DRAFT July 5, 2013 client and the server. We define key provisioning schemes (section 7.2) that profiles of this framework may take advantage of. 2.3 Outline of Access Control Framework We briefly outline the roles, the targeted access control procedure, the default components of the Access Control Framework (ACF) and what parts are specified by profiles. The roles are: - A Resource Owner specifying the policies for access to the resources. - An Authorization Server (AS) performing the authorization decision based on the access control policies and provisioned with one or more trusted keys from the Resource Server. - A potentially constrained Resource Server (RS) hosting resources and provisioned with one or more trusted keys from the AS. - An Origin Client (OC) requesting authorization and access to a resource. As there may be client intermediaries, e.g. forward proxies, the actual CoAP client requesting the resource server may be different from the origin client. When there are no other clients to confuse with, we refer to the origin client simply as "the client". +-----------+ | Resource | | Owner | | | +-----------+ +--------+ +-----------+ | |--(A)-- Assertion Request ---------->| Authori- | | | | zation | | |<-(B)-- Assertion, Base Credentials ---| Server | | Origin | +-----------+ | Client | | | +-----------+ | |--(C)- Protected Request, Assertion -->| Resource | | | | Server | | |<-(D)- Protected Response -------------| | +--------+ +-----------+ Expires January 6, 2014 [Page 8] INTERNET DRAFT July 5, 2013 Figure 1: Roles and access control procedure The default procedure for resource access works as follows (see Figure 1): The client requests (A) from the authorization server an assertion for access to the resource. The authorization server makes the authorization decision on behalf of the resource owner and, if granted, responds (B) to the client with an Assertion and optionally one or more Base Credentials to be used for protecting the message exchange between client and resource server. A base credential may e.g. be the public key of the resource server, a public key certificate of the origin client, or a so-called Bind Key (Section 7.2.2) bootstrapping the trust relation between the authorization server and resource server. Additional information may be conveyed between authorization server and the origin client, e.g. which Message Protection Profile (see below) is being used in communication with the resource server. The client attaches the assertion to the request (C) submitted to the resource server, where the request/response message exchange is protected either using communication security, e.g. DTLS [RFC6347], or using object security, e.g. using JWE and JWS [I-D.ietf-jose-json- web-encryption][I-D.ietf-jose-json-web-signature]. There are also hybrid cases where both communication and object security is used, e.g. when the assertion signed by the authorization server is additionally signed and/or encrypted by the client and sent over DTLS. In either case, the message protection may be based on a key provisioning scheme (Section 7.2) using base credentials provided by the authorization server. Alternatively, DTLS can be based on pre- provisioned credentials as defined by the security modes in [I- D.ietf-core-coap], or other secure provisioning schemes. The resource server verifies the assertion using a trusted key, evaluates potential local conditions and, if all conditions are met, allows the requested action on the resource. Finally the resource server responds (D) to the request. The response uses the same protected message exchange mechanism as the request. The Access Control Framework (ACF) as specified in this document defines the roles (Section 3), the overall architecture and message flow (presented in this section), the embedding of the assertion in CoAP (Section 4.3), the extended access control lists (Section 7.1), and key provisioning schemes between origin client and resource server enabled by the authorization server (Section 7.2). Expires January 6, 2014 [Page 9] INTERNET DRAFT July 5, 2013 The reason for including key management in the access control framework is because authorization and access control are intimately linked to authentication and secure messaging: Authorization is bound to certain entity, and secure messaging enables exclusive access. Therefore it is in line with the trust model and a clear gain in provisioning effort, and computational and memory performance to use a common key management for the different security functions. The different applications of this access control framework in the different use cases are expressed in terms of profiles. A profile of the access control framework consists of an Assertion Profile and a client-server Message Protection Profile: - An Assertion Profile specifies the assertion format including the procedure for signing and verifying the assertion, and how trusted AS keys are used (Section 4). - A Message Protection Profile describes the protection of the resource request/response, what keys are used (including base credentials) and how (Section 5). 3. Roles This section describes the roles of the components in the authorization framework. 3.1 Resource Owner The resource owner specifies the policies for access to the resources. The access policy language or format for expressing policy related conditions may be specified in an assertion profile if it affects the format of the assertion or procedures related to composing, signing, verifying or parsing the assertion. The role of the resource owner is obviously an important one, but is not directly involved in the access control framework specified here. 3.2 Authorization Server The authorization server is acting on behalf of the resource owner and has several functions: 1. Storing and using trusted keys of the resource server (trusted RS keys). The establishment and regular re-establishment of the trusted Expires January 6, 2014 [Page 10] INTERNET DRAFT July 5, 2013 keys is out of scope. 2. Performing the authorization decision. How this is done is out of scope. 3. Generating, signing, and issuing assertions for requesting clients to be verified by a resource server and potentially intermediate nodes. The details are specified in the assertion profile. 4. Communicating with clients (receiving access request, responding with assertion, base credentials or other data). The details are specified in the message protection profile. NOTE The authorization server must have knowledge about its resource servers' supported assertion and communication security profiles. 3.3 Client A client wishing to access a resource, requests an assertion from the authorization server. If the request is granted it receives an assertion, and optionally base credentials and other information, to use when communicating with a resource server. The client requests access to a resource from the resource server and attaches the assertion. The origin client may need to encrypt and/or sign the assertion before sending it to the resource server. The base credentials may be used to protect message exchanges between client and resource server. The procedures are described in the message protection profile. 3.4 Resource Server The resource server, is a potentially constrained device hosting the resource owner's resources. It receives, processes and responds to client requests. The resource server has an established trust relation with an authorization server (identified with a trusted AS identifier), manifested through one or more trusted AS keys. The resource server verifies that an assertion received in an access request is valid and from a trusted source involving a trusted AS key. If the assertion depends on the client's identity, the resource server verifies that the requesting client is the same as the entity authorized by the assertion. The assertion verification and message protection procedures are specified in the respective profiles. Expires January 6, 2014 [Page 11] INTERNET DRAFT July 5, 2013 4. Assertion profiles The assertion is a secure object containing authorization information passed from the authorization server via a client to the resource server. The assertion is digitally signed by the authorization server to enable data origin verification and integrity protection. The assertion format is specified in assertion profile, an example is given in Section 8.1. 4.1 Assertion requirements In order to enable the resource server to enforce the authorization decision, the assertion SHALL provide the following information: o Which resource does the decision apply to. o Which action (GET, PUT, POST, DELETE) does the decision apply to. o Which client does the decision apply to, and how can this client be authenticated (if necessary). o Which authorization server has issued this assertion (AS identifier). This information MAY be implicit from the signature of the assertion. o Under what other conditions is the assertion valid (expiration date, conditions evaluated by the resource server at access time). The assertion SHALL include an Assertion Identifier which is unique for a given resource server. If the ACF SSK key provisioning scheme (Section 7.2.2) is used, the assertion SHALL include a Nonce N which is different for different assertions of a given resource server. The nonce may be the assertion identifier. The assertion MUST be signed by the authorization server such that it can be verified by the resource server using a trusted key. An assertion MAY be signed with a secret symmetric key, which is then called the Assertion Key (AK). An assertion MAY be signed with a private key in an asymmetric signature scheme, for example the authorization server's private key (PrK_AS). The resource server, or other nodes verifying the assertion, MUST have access to the relevant key (AK or PK_AS) at the time of performing the verification. The case of an asymmetric signature scheme is RECOMMENDED if, in addition to the resource server, an intermediary node should also be able to verify the assertion, since the intermediary would only require to be provisioned with a public key rather than a secret key. Expires January 6, 2014 [Page 12] INTERNET DRAFT July 5, 2013 The assertion MAY be (partially) encrypted and signed by the origin client, if so specified in the message protection profile. The assertion identifier SHOULD NOT be encrypted. If the ACF SSK key provisioning scheme is used, the Nonce, or Assertion Identifier if that is used as nonce, SHALL NOT be encrypted. When using a communication security profile, assertions MAY be cached (Section 5.1.1) and there is no need for replay protection, assuming the communication security protocol supports replay protection (e.g. DTLS, IPsec). When using an object security profile, assertions SHALL NOT be cached and assertion replay protection SHALL be applied (Section 5.2.4). 4.2 Assertion wrapping Since assertions are to be consumed by constrained devices, the protection of the assertion must be lightweight and compact. For example XML-Signature [XMLDSig] is not considered to fulfill this requirement. This specification RECOMMENDS the use of JSON Web Signatures (JWS) [I-D.ietf-jose-json-web-signature] as a means of signing assertions. It is furthermore RECOMMENDED to use the JWS Compact Serialization in order to further reduce the size of the signed assertion object. 4.3 Assertion transport The assertion needs to be delivered to the Resource Server in some way. There are several possible methods to achieve this: 1. One alternative is to transmit the assertion in CoAP as a URI query value. When using this option it is RECOMMENDED to use the key "authz". A limitation with this approach is that the URI query option in CoAP is defined as Unsafe-to-Forward, meaning that a potential forward proxy that does not understand the authorization query would not forward such a request. 2. Another alternative is to transport the assertion using a dedicated CoAP option. Such an option SHOULD use an option number in the "Specification Required" range of 256..2047. The option SHOULD be defined as Critical, and Safe-to-Forward. It SHOULD NOT be used as cache-key and it SHOULD NOT be repeated. The content format SHOULD be string and the Length between 1-1023 bytes. A Default value SHOULD NOT be specified. 3. A third alternative, if DTLS is used for communication security, is a DTLS adaptation of the TLS Authorization Extensions [RFC5878]. Expires January 6, 2014 [Page 13] INTERNET DRAFT July 5, 2013 This provides an alternative to the TLS extension defined in Section 8.2. 5. Message protection profiles The message protection between origin client and resource server is specified in a profile. The request/response messages may be protected with communication security (e.g. DTLS, IPsec) or with object security (e.g. JWE, JWS). The message protection profile SHALL specify: o Which security protocol is used for authentication and secure messaging between origin client and resource server. o Which cipher suites are used, and how cipher suite negotiations of the security protocol are used. o Whether the assertion is encrypted and/or signed by the client. o Which keys are used and how they are obtained a) in the origin client (including the use of base credentials) and b) in the resource server. o Which CoAP security mode is assumed (if any, [I-D.ietf-core-coap]) and what ACF key provisioning scheme (if any, section 7.2). o How to handle intermediary nodes (Section 6). o Processing in origin client, resource server and intermediary nodes at sending and receiving messages. A resource server SHALL support one and only one message protection profile, either a communication security profile or an object security profile. How the authorization server gets information about the message protection profile supported by the resource server is not in scope. 5.1 Communication security profile A communication security profile defines the detailed security protocol used between client and resource server in the case when there are two security protocol phases: One security establishment phase performing authentication and key establishment (such as DTLS handshake protocol or IKE) and one secure messaging phase (such as DTLS record protocol or IPsec) wherein CoAP messages are sent. Expires January 6, 2014 [Page 14] INTERNET DRAFT July 5, 2013 Communication security protocols like DTLS and IPsec provides protection to the entire application layer protocol message including headers, assertion and payload. The "detailed security protocol" in the communication security profile may also include object security components, as is illustrated in the examples below. Example 1: The assertion is a secure object in itself, being signed by the authorization server, but it may be necessary to also prove the intent of the authorized client to perform the request it is authorized with. This may be achieved by an authentication protocol authenticating a client as described in the assertion. Alternatively it may be addressed with a client signature on the assertion. Example 2: The content of the assertion may require confidentiality protection between client and server e.g. for privacy reasons. This may be achieved by an end-to-end communication security protocol (see below) which encrypts the messages. Alternatively it may be addressed with encryption by the client of the assertion. We distinguish between the end-to-end communication security setting where the communication security protocol runs between origin client and resource server, and the hop-by-hop security setting where there are intermediary nodes (Section 6.1). In the end-to-end security setting, the resource server authenticates the origin client. The resource server SHALL verify that the subject authorized with the assertion coincides with the authenticated client. In the end-to-end security setting the client signature on the assertion MAY be omitted (compare DTLS hop-by-hop, Section 6.1). If communication security is established using public keys, the public key of the client MAY be replaced with a public key identifier in the assertion. 5.1.1 Assertion caching in resource server (informational) There may be cases of repeated access requests from one client where a single assertion could provide authorization of all requests, e.g. requests within the life time of the assertion. To avoid repeatedly sending the same assertion in each request, assertions could be cached. Expires January 6, 2014 [Page 15] INTERNET DRAFT July 5, 2013 Assertions may support caching/multiple use i.e. that the same assertion is valid for multiple requests. The same assertion may be sent multiple times within a secure session, but if the resource server supports assertion caching this is not recommended. Assertion caching shall only be used with session based communication security profiles and if supported by the resource server. The assertion shall be deleted when the session expires. Assertions shall be verified before caching. Not all parts of the assertion need to be cached. If caching is done, the assertion identifier, client identifier, local conditions, resource identifier, and the action shall be cached. Local conditions in the assertion shall be verified at each request or, considering Observe (Section 6.3), before each response. After communication security has been established with a resource server supporting caching of assertions, on reception of a request, the following access control priority sequence shall be used: 1) If the client identifier is category A (Section 7.1), the request is granted. In this case, further access control processing is omitted. 2) Else if the client identifier is category B check for a cache hit. If a matching assertion is found, verify the local conditions and grant access if they are fulfilled. 3) Else if the request contains an assertion verify it, and if successful, cache it. Then verify the local conditions, and if valid then grant access. TBD Assertion caching in proxies. TBD Response code if assertion is cached 5.2 Object security profile The authentication protocol for establishing the context of a secure session, e.g. the DTLS handshake, may be a significant cost for a constrained device. An alternative is to not have a security establishment phase and instead send secure objects in CoAP request and response. The requirements on message protection profiles as listed in the Expires January 6, 2014 [Page 16] INTERNET DRAFT July 5, 2013 beginning of section 5 apply. In this case the required security protocol is manifested through the processing and passing of the secure objects. The assertion is a secure object in itself which is passed in the CoAP request. In addition to the assertion, the CoAP request and the CoAP response may contain a secure payload object. The object security profile defines what object format is being used, e.g. JWE [I-D.ietf-jose-json-web-encryption]. Assertions MUST NOT be cached in case of an object security profile. Assertion are one-time only, and the resource server SHALL maintain a replay cache (Section 5.2.4). Different request methods (GET/PUT/POST/DELETE) may have different secure object formats for request and response. 5.2.1 GET Assertions for GET requests SHOULD be signed by the client. The client signature SHALL use the key indicated by the client identifier in the assertion. In some cases, e.g. extremely constrained devices and other settings where implicit authentication is feasible, the client signature MAY be omitted. The assertion MAY be (partially) encrypted by the client. If the resource request is authorized, then the requested action is performed and what would have been the unprotected CoAP response payload SHALL be wrapped into a secure object and sent as response payload. The GET response SHALL be integrity protected and MAY be encrypted. NOTE that in the case of implicit authentication (no client signature on the assertion) the resource server does not establish the identity of the requesting client. However, by protecting the response for the authorized client, only the authorized client can get access to the response. This is however an entry for DoS so should be used only when the potential security consequences are considered acceptable. 5.2.2 PUT/POST In the PUT/POST request, the assertion or the payload SHALL be signed by the client. The assertion and the payload MAY be (partially) encrypted, e.g. for privacy reasons. Expires January 6, 2014 [Page 17] INTERNET DRAFT July 5, 2013 The object secure PUT/POST response payload MAY be signed or encrypted by the resource server. 5.2.3 DELETE Assertions for a DELETE request SHALL be signed by the client. The object secure DELETE response payload MAY be signed or encrypted by the resource server. 5.2.4 Assertion replay protection (informational) In case an assertion is eavesdropped it may be replayed at a later stage by an unauthorized party and cause unnecessary processing and power consumption in the resource server. In the case of a communication security protocol with replay protection this is not an issue. In the case of an object security protocol, even if the assertion may be in parts encrypted, it may nevertheless be eavesdropped and replayed. For this purpose we recommend the use of a Replay Cache where the latest legitimate requests are being stored, as outlined in this section. For each entry in the replay cache there are two values: the Assertion Identifier and the associated assertion expiration date. The replay cache is being managed in the following way during reception of object secured requests. When a request is received: 1. The expiration date of the assertion is checked. 2. The identifier of the assertion is matched against the replay cache. If any of these verifications fail, the request is immediately silently dropped to avoid unnecessary processing. The resource server may also increase a counter that an invalid request was received, such a counter may be used as input for a decision to e.g. stop receiving or go to sleep a randomized time interval. If the verifications are successful then the signature of the assertion is verified. If that is also successful, then the a new entry is added to the replay cache. Before a new entry is being added, the cache is cleaned from entries associated to expired assertions. If the cleaned replay cache is full, the new entry pushes out the entry with shortest remaining lifetime, and if several of equal remaining lifetimes, the oldest of these is pushed out. The size of the replay cache and assertion lifetimes should be tuned so that the replay cache can contain all entries corresponding to Expires January 6, 2014 [Page 18] INTERNET DRAFT July 5, 2013 valid assertions. The importance of this recommendation depends on the impact of processing invalid requests. 6. Intermediary processing and notifications This section describes the security implications of intermediary processing and notifications for access control. 6.1 Intermediary nodes There may be intermediary nodes between origin client and resource server, including forward proxies, reverse proxies, cross-proxies, gateways, etc. From an access control point of view the resource server SHOULD be able to verify that a received CoAP request is originating from the origin client referenced in the received assertion. This has implications on the assertion and message protection profiles. We distinguish between the end-to-end security setting where no intermediary nodes need be trusted and the hop-by-hop security setting where at least one intermediary node must be trusted. Note that an object security profile may provide end-to-end security independently of proxies, but would not allow any inspection or modification of the payload. DTLS generally needs to be hop-by-hop in case of proxies, this requires some degree of trust in a proxy which may not be acceptable for some applications. A resource server sending back the response via the forward proxy trusts the forward proxy with the plain text response (e.g. a GET response) and that the proxy has established secure communication with the origin client. In the hop-by-hop setting, neither DTLS nor CoAP offers any means for resource server to authenticate the origin client. If the resource server has established DTLS with a forward proxy which proxies requests from an origin client, then the assertion MUST be signed by the origin client in addition to the authorization server signature. The resource server can not authenticate the origin client directly, but it can infer from a correctly signed valid and fresh assertion that the origin client is authorized and has an intent to perform the request. Using the authorization server as a trusted party it is possible to define a message protection profile which also provides base Expires January 6, 2014 [Page 19] INTERNET DRAFT July 5, 2013 credentials for proxies or for clients use of proxies, which support DTLS establishment between origin client and a proxy (Section 7.3.1). 6.2 Mirror Server The access control framework can also be applied to the scenario where a mirror server as defined in [I-D.vial-core-mirror-proxy] is present. In such a scenario, the resource servers behave as the clients of the mirror server. The access control enforcement in this case, would be made at the mirror server instead of in a constrained resource server, and the trusted AS keys would have to be provisioned to the mirror server. However, to a client wishing to access a resource, the mirror server behaves as any other resource server and is indistinguishable (transparent), thereby requiring no change for the communication between client and the mirror server. The communication between the mirror server and the constrained resource server may or may not be secured, and is oblivious to the ACF profiles used between the client and the mirror server. 6.3 Observe The access control framework can also be applied, as it is, in the case where the CoAP observe option [I-D.ietf-core-observe] is used. With the observe option, the clients can register an interest in a particular resource by sending a CoAP request containing the observe option to a resource server. The resource server would in this case maintain the state information for this expressed interest and send responses on state changes only as long as the assertion and local conditions presented in the original interest request are valid. The local conditions may need to be verified at each state change. Once the assertion expires, the resource server will remove any state information for the interest expressed. The client would then have to send a new CoAP request with an observe option expressing interest and a new assertion for demonstrating that it is allowed access. 7. Trust management The access control framework specified here involves at least three entities, and thus a number of different trust relations are possible. The framework does not make any assumptions on the a priori trust relationship between origin client and resource server (if any). The access control framework requires however an a priori trust establishment between resource server and authorization server manifested, in particular, in one or more trusted AS keys stored in Expires January 6, 2014 [Page 20] INTERNET DRAFT July 5, 2013 the resource server. How these keys are established is out of scope, but we define different categories of keys in Section 7.1. The primary purpose for the AS keys is to enable the resource server to verify that an assertion received in a request from a client was issued by the authorization server and has not been modified. Data origin authentication and integrity verification is performed by verifying a digital signature of the assertion. This digital signature may either be a private key signature generated with the private key of the authorization server (PrK_AS), or a Message Authentication Code (MAC) calculated with a secret symmetric Assertion Key (AK) unique for this resource server and assertion. In the case of a private key signature, the resource server must have access to the public key of the authorization server (PK_AS) at the time of verifying the assertion. In the case of a MAC, the resource server must have access to AK at the time of verifying the assertion. Two key provisioning schemes are defined in this section. The trusted AS keys may also be utilized for other purposes than to support assertion verification. By means of authentication and authorization of a client, the authorization server may invoke a trust relation between the resource server and the client. This is the main purpose of the key provisioning schemes detailed later in this section. For example, the AS may create a certificate of a public key of the client which can be verified with an AS key. As another example, the AS may create a secret Bind Key for the origin client which the resource server can derive from a nonce and an AS key (Section 7.2.2). The public key or the bind key of the client can subsequently be used by the resource server e.g. for authentication of and secure messaging with a hitherto unknown client. The latter is detailed in the message protection profiles. 7.1 Access Control Lists Considering that different deployments may have very different access control requirements we want to keep the simple access control scheme indicated in [I-D.ietf-core-coap], and allow a gradual extension to comply with more advanced access control settings. The use of an access control lists in the resource server containing identities of exchanged public keys, or pre-shared keys, of clients [I-D.ietf-core-coap] provides an easily described criterion for determining if a requesting client is allowed to establish secure communications: Clients that can be authenticated as one in the list are allowed. In the absence of any other access control, authenticated clients are also implicitly authorized to access any resource ("all-or-nothing" access control). Expires January 6, 2014 [Page 21] INTERNET DRAFT July 5, 2013 Similarly with a list of root trust anchors in security mode Certificate [I-D.ietf-core-coap]: Clients that can be authenticated using a public key certificate signed by a trust root from the list, are allowed to establish secure communication (and potentially to become implicitly authorized). In this case the list contains identities of trust roots which are trusted with issuing certificates to authorized clients. We propose to maintain backward compatibility with these access control lists but at the same time enable a distinction between authentication/secure communication and authorization. There SHALL be two categories of client keys/identities in the access control lists of resource servers: o Category A: identities or keys of clients which are allowed to set up secure communication to a resource server, and to access all resources. o Category B: identities or keys of clients which are allowed to set up secure communication, but access to a resource requires an appropriate valid assertion. Requests from clients in category A requires no assertion and can bypass the access control. Clients that have been authorized access to a resource by an authorization server should obviously have the right to set up secure communication to this resource server, and thus are in category B. Hence the authorization server constitutes a trust root for clients of category B. The root trust anchor is in this case a trusted AS key. Summarizing, there are four kinds of access control lists: Category A, its trust anchors, Category B, and its trust anchors. Not all lists need to be populated. Implementations complying with the security mode RawPublicKey [I-D.ietf-core-coap] define access control lists of category A. For implementations complying with the present specification category B trust anchors are necessary. In Section 7.3 we show examples that the latter access control list may also be sufficient. One example of a member of the category B access control list is a pre-provisioned, semi-trusted forward proxy which is allowed to set up secure communication with a resource server, but without gaining access to any resource. NOTES Expires January 6, 2014 [Page 22] INTERNET DRAFT July 5, 2013 1. While the trusted AS key is a category B trust anchor, the property of trusted AS keys relate to verification of assertions, and not all category B trust anchors are necessarily used for verifying assertions. 2. For object security the trusted AS keys are sufficient for determining access rights as there is no need to set up secure communication first. There is no access without assertion in the object security setting - corresponding to category A of the communication security setting. The reason for excluding this option is that in the object security setting there is always at least one object to be verified by the resource server and there is no generality lost in assuming that this object is the assertion. TBD - change of access control lists: Can the ACL in itself be a resource that can be accessed like any other and whose changes can be authorized with the methods proposed here? 7.2 Key provisioning schemes There are two basic key provisioning schemes defined in this access control framework: the ACF PK scheme built on public keys exchanged between RS and AS, and the ACF SSK scheme built on a shared secret key between RS and AS. The key provisioning schemes define which keys are assumed to be provisioned to what nodes, and how these keys can be used for deriving and/or provisioning of other keys. The key provisioning schemes apply both to communication security and object security. The assertion is by definition a secure object. The key management is more complex for communication security than object security and assertions, since the former involves key management both for communication security and for secure objects. Note that these key provisioning schemes are complementing the Security Modes defined in the DTLS binding of CoAP [I-D.ietf-core- coap] and may replace the need for provisioning keys between resource server and a client. See examples of Section 7.3. 7.2.1 ACF PK Scheme The ACF PK scheme assumes that the public key of the resource server, PK_RS, is provisioned to the authorization server and vice-versa; the public key of the assertion server PK_AS is provisioned to the resource server. The trusted AS key is in this case PK_AS. With this scheme the assertion is signed by the authorization server with its private key PrK_AS and verified by the resource server using PK_AS. Expires January 6, 2014 [Page 23] INTERNET DRAFT July 5, 2013 The content of the assertion provides a secure information channel from the authorization server to the resource server, and may be used as a means for provisioning. For example, the public key of the origin client, PK_OC transported within the signed assertion to the resource server is integrity protected. When an origin client requests an assertion for access to a resource, the public key of this resource server can be attached in the response as one of the base credentials, as a means to provision PK_RS to this origin client. As an alternative to provisioning PK_OC to the resource server in an assertion, the authorization server may issue a public key certificate for PK_OC as a base credential together with the response carrying the assertion. This certificate may then be used by the origin client in a certificate based authentication protocol with the resource server. PK_AS is in this case a category A or category B trust anchor. A similar provisioning scheme is also applicable to trust establishment with a forward proxy, see Section 7.3.1. 7.2.2 ACF SSK Scheme The ACF SSK scheme assumes that there is a 128 bit shared secret key SSK between resource server and authorization server, and specifies how to derive the assertion key AK and the Bind Key BK from SSK. The trusted AS key is in this case SSK. The assertion is signed by the authorization server with AK and verified by the resource server with AK. We assume that the shared secret key SSK is pseudo-random, i.e. not biased. It may for example be the result of a randomness extraction step from an initial key material IKM as defined in [RFC5869]. AK and BK is derived from SSK by the authorization server and resource server through a data expansion step as defined in [RFC5246]: P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ... where '+' indicates concatenation and A() is defined as: A(0) = seed A(i) = HMAC_hash(secret, A(i-1)) Expires January 6, 2014 [Page 24] INTERNET DRAFT July 5, 2013 In the present case: o hash is SHA-256, o 'secret' is SSK - the shared secret, and o 'seed' is the nonce, N. The nonce N associated to the resource access request is defined by the authorization server. A Nonce SHALL NOT be reused with the same SSK. Since the nonce is required for key derivation, it must be available when they key is needed by the resource server. With one iteration of the P_SHA256, the output data of 256 bits is defined to be the concatenation of the two 128 bit keys AK and BK, where AK is the Assertion Key and BK is the Bind Key: AK + BK = P_SHA256(SSK, N) How the assertion key and the bind key is used in protecting the assertion and client-server communication, respectively, is defined in an ACF profile. 7.3 Key provisioning examples The CoAP security modes makes assumptions on what keys are provisioned in the resource server. o In security mode PreSharedKey there is a list of keys corresponding to trusted nodes. With the terminology in Section 7.1, these clients may be of category A or B. o In security mode RawPublicKey there is a list of identities of trusted nodes, these clients may be of category A or B. o In security mode Certificate there is a list of trust anchors, these trust anchors may be of category A or B. This access control framework requires the provisioning of a trusted AS key. In either of the cases above, the additional effort of provisioning a trusted AS key, which in particular is a category B trust anchor, is negligible. This section takes the opposite standpoint: assuming the use of this access control framework with the authorization server functionality and trusted AS key provisioned to the resource server, what other keys (if any) need to be pre-provisioned to the resource server and what keys can be communicated during the access request procedure? Expires January 6, 2014 [Page 25] INTERNET DRAFT July 5, 2013 Phrased differently: To what extent could this access control framework remove the need for, or simplify, the provisioning of keys? 7.3.1 The authorization server as certification authority Given that the trusted AS key may be used as a category A/B trust anchor, the authorization server may issue public key certificates to origin clients that are verified in the resource server. This removes the need to pre-provision client public keys to the resource server. The origin client may also use certificates signed by the authorization server to set up DTLS with an intermediary node such as a forward proxy. This would require the proxy to be provisioned with PK_AS, which however is a natural assumption: A forward proxy may also perform firewall functionality on behalf of the resource server; to verify some properties of the assertions and drop requests with e.g. expired assertions, assertions with invalid signatures, etc. Alternatively, the TLS Authorization Extensions [RFC5878] may be used with the assertion replacing the need for a certificate. 7.3.2 The authorization server for configuration of raw public keys Since the origin client has a secure channel to the authorization server which is a trusted party, the origin client can obtain trusted information directly from the authorization server. The public key of the resource server can e.g. be provided as a base credential, removing the need to pre-provision resource server public key to the origin client. 7.3.3 The assertion as an authentication token There are two aspects of authentication tokens considered here. 1. The assertion may contain the public key of the client thereby carrying authentication information about the client. 2. The assertion may be signed by the client thereby constitute a verifiable token for authentication of the client. Given that the assertion contains the public key of the client, the resource server may use the assertion to establish DTLS in security mode RawPublicKey with the client, removing the need to pre-provision client public keys to the resource server or to pre-provision or use client public key certificates. Expires January 6, 2014 [Page 26] INTERNET DRAFT July 5, 2013 The use of an origin client signature of the assertion provides an additional means for authenticating the client, removing the need for a separate secure payload object, or providing authentication information over multiple hops. 7.3.4 Using the assertion to transport the nonce The assertion provides transport of the nonce to the origin client and resource server. In the ACF SSK scheme, with object security, the transportation of nonce in the assertion enables the resource server to derive of the bind key, which removes the need to pre-provision shared secret keys between origin client and resource server. 7.3.5 TLS extension for transport of nonce The authentication protocol may provide transport of the nonce between origin client and resource server. In the ACF SSK scheme, with DTLS, the transportation of a nonce in a dedicated TLS extension (Section 8.2) enables the resource server to derive the bind key, which removes the need to pre-provision shared secret keys between origin client and resource server. 8. ACF Profiles 8.1 Assertion Profile: Compact SAML-XACML In this section we give an example of an assertion profile, using SAML [SAML] and XACML [XACML]. This profile is based on the SAML 2.0 Profile of XACML Version 2.0 [SAML-XACML] with a number of significant changes to this profile, in order to account for the constrained nature of the resource host. Since the full syntax of XACML Requests, Responses, and SAML assertions includes a large number of features, we have defined a subset of both standards, in order to simplify the processing on the resource server. Furthermore the XML representation of this subset is too verbose for efficient transmission over limited channels, therefore we have defined a compact JSON-based notation of this SAML and XACML subset. SAML assertions have the following required elements: Expires January 6, 2014 [Page 27] INTERNET DRAFT July 5, 2013 - An assertion identifier - The issue instant - The SAML version number - The Issuer of the assertion Furthermore the following optional elements are relevant for the purposes of this profile: - The Subject of the assertion - A Statement (in our case an authorization statement) The SAML 2.0 Profile of XACML defines an XACML authorization decision statement as a sequence of an XACML Response and an optional XACML Request. It is obvious in our case that the Request MUST be part of the statement to give the necessary context, otherwise it would be impossible to determine what the Response applies to. The following restrictions have been defined to create a useful subset of the SAML assertion format: - The assertion identifier SHALL be a 128 bit random number encoded as UUID [RFC4122]. - The issue instant is encoded in UTC form without time zone component. - The SAML version number is implicitly assumed to have the value "2.0". - The encoding of the Issuer is up to the implementers, but it SHOULD enable consumers of the assertion to determine the identity of the trusted entity that issued this assertion, and thus to derive the key used to verify the signature of the assertion. - The Subject SHALL either contain a subject identifier that can be used to bind the assertion to a subject in some way that is implicit to the consumer, or a subject's public key that can be used in an authentication scheme. - The Statement SHALL NOT contain an XACML Response. The Response is implicitly assumed to contain a PERMIT decision. An entity generating assertion MUST NOT generate assertions for decisions other than PERMIT. If the XACML Response contained XACML Obligations these MUST be included in the Statement. It is RECOMMENDED not to write Expires January 6, 2014 [Page 28] INTERNET DRAFT July 5, 2013 Policies that would result in more than one Obligation in a Response. The resource server MUST know how to process the Obligation, otherwise it MUST reject the assertion and deny the request with error message. - The XACML Request MUST contain the two single attributes identifying the resource and the action. The subject identifier MUST NOT be part of the Request since it is inferred from the SAML subject identifier. The resource identifier SHALL be the resource URI, without the scheme name. The query part MAY also be omitted if that level of granularity is not desired in the access control policies. The action identifier SHALL be one of the values: GET, POST, PUT, DELETE. In the case of a POST or PUT action, the payload value of the action SHALL be encoded as an action attribute with the attribute identifier "VAL". The entity generating the assertion MUST discard all other attributes from the Request. The following compact encoding defines the assertion format in this profile, listing the JSON elements in the order in which they are expected to appear in the final assertion object: - The assertion identifier SHALL use the member name "ID". - The issue instant SHALL use the member name "II". - The Issuer SHALL use the member name "IS". - The Subject element SHALL use the member name "SK" if it represents a subject-key, where it is assumed that the consuming device and the issuer of the assertion share a common understanding of the type of key that is encoded in that value. If the Subject element is an identifier, it SHALL use the member name "SU". - The Statement SHALL be a JSON object with the name "ST" containing the following members: o If the XACML Response contained any Obligations, they SHALL be represented in JSON objects or members with the name "OB", the content or value format of these objects MUST be understood by the consuming device. o The action identifier SHALL use the member name "ACT". o If the action is a PUT or POST, the payload value SHALL use the member name "VAL". o The resource identifier SHALL use the member name "RES". Expires January 6, 2014 [Page 29] INTERNET DRAFT July 5, 2013 In order to protect the integrity of the assertion JWS [I-D.ietf- jose-json-web-signature] SHALL be used. If only the AS is supposed to sign the assertion it is RECOMMENDED to use JWS Compact Serialization, if an additional signature by the the origin client is required (see Sections 5.2.1-5.2.3) it is RECOMMENDED to use JWS JSON Serialization. If the origin client is required to encrypt the assertion, this MUST be performed in the same way as specified for the payload in Section 8.3, where the encrypted plaintext is the JWS Compact Serialization of the assertion signed by the AS. Implementations using the ACF PK Scheme (see Section 7.2.1) MUST support the ES256 algorithm. PrK_AS MUST be used for generating the signature and PK_AS for verifying the signature. Implementations using the ACF SSK Scheme (see Section 7.2.2) MUST support the HS256 algorithm. The Assertion Key AK MUST be used as key for generating the message authentication code. The algorithms corresponding to the identifiers above are specified in [I-D.ietf-jose-json-web-algorithms]. In order to verify the assertion, the RS needs to perform the following steps: 1. Verify if the assertion has expired. This profile assumes that each RS uses a fixed validity time for any assertion. Therefore expiration can be easily checked by verifying the time elapsed since the issue instant. In cases where the RS lacks the means to measure time reliably, this step is skipped. 2. Verify if the assertion was issued by a trusted AS, by checking the Issuer field of the assertion. 3. Verify that the assertion applies to the CoAP request, i.e. that it applies to the same resource and action. 4. Verify that the origin client is the Subject of the assertion. This might not be possible if there are intermediary nodes, in this case the assertion can have an additional signature by the OC to confirm its intent to perform the authorized action. Note that certain actions allow implicit authentication (see Sections 5.2.1- 5.2.3), in which case this step can be skipped. 5. Verify the AS signature of the assertion. 6. If the assertion contains any Obligations, check that these are satisfied. Expires January 6, 2014 [Page 30] INTERNET DRAFT July 5, 2013 The following example illustrates an assertion generated according to this profile, without the JWS signature: 01 { 02 "ID": "ID_ffda55f9...097bdd21e6", 03 "II": "2013-02-15T10:02:52Z", 04 "IS": "AAA-Server", 05 "SK": "BvDgLAXSHe...0RLhfwS1fue", 06 "ST": { 07 "OB":{ 08 "NB":"09:00:00Z", 09 "NA":"17:00:00Z" 10 }, 11 "ACT": "GET" 12 "RES": "node346/tempSensor" 13 } 14 } Note that the assertion shown would have a size of 208 bytes without pretty printing. The corresponding assertion following the XML representation of SAML and XACML would be 2281 bytes large. Also note that this assertion carries an obligation on the time interval during which access is allowed (NB = not before, NA = not after). This obligation must be pre-defined on the consuming device so that it can parse and enforce it. 8.2 Communication Security Profile: DTLS PSK with Bind Key This section gives an example of a communication security profile based on DTLS PSK [RFC4279] using the bind key (BK) of the ACF SSK key provisioning scheme as if it was a pre-shared key. PSK-cipher suites and cipher suite negotiations are identical. The setup is identical to the CoAP security mode PreSharedKey [I- D.ietf-core-coap] with the exception that the key BK is not pre- provisioned to the resource server but needs to be derived from a nonce and the shared secret key SSK (Section 7.2.2). Using the coaps:// schema, DTLS security context is established before the CoAP request in which the assertion is sent. Therefore, in order to derive a bind key to be used in the DTLS handshake the nonce needs also to be sent in the DTLS handshake. Expires January 6, 2014 [Page 31] INTERNET DRAFT July 5, 2013 When using this profile in an end-to-end communication security setting, the nonce SHALL be included as a DTLS extension in ClientHello. The extension type is defined as follows: enum { key_derivation(19), (65535) } ExtensionType; The "extension_data" field of this extension contains a "key_derivation_data" value, defined as follows: struct { opaque nonce[16]; opaque as_id<1..32>; } key_derivation_data The following modifications to the DTLS handshake SHALL apply: Before composing the ClientHello message, the origin client reads out the nonce and the AS identifier from the assertion and composes the key_derivation extension as defined above. This extension is sent in the ClientHello message. After receiving the ClientHello message, the resource server looks up the SSK based on the AS identifier, and computes BK as described in section 7.2.2, using the provided nonce. BK is used as the PSK from here on, and the protocol proceeds as specified in [RFC4279]. 8.3 Object Security Profile: JWE-protected CoAP payload This section gives an example of an object security profile, i.e. protection of CoAP payload by means of secure objects. When using this profile the Javascript Object Signing and Encryption (JOSE) standards SHALL be used. Section 5.2 and its subsections specify when a payload or assertion is to be signed and encrypted. If a payload is to be signed but not encrypted the JSON Web Signature (JWS) standard [I-D.ietf-jose-json-web-signature] SHALL be used. If a payload is to be signed and encrypted the JSON Web Encryption (JWE) standard [I-D.ietf-jose-json-web-encryption] SHALL be used. If only a single signature is needed on the assertion, it is RECOMMENDED to use the Compact Serialization instead of the JSON Serialization in order to keep the payload size small. Implementations using the ACF PK Scheme (see Section 7.2.1), MUST Expires January 6, 2014 [Page 32] INTERNET DRAFT July 5, 2013 support the ES256 JWS algorithm. For JWE the ECDH-ES key sharing algorithms MUST be supported, and for authenticated encryption the A128GCM algorithm MUST be supported. Implementations using the ACF SSK Scheme (see Section 7.2.2) MUST support the HS256 algorithms for JWS. For JWE the dir key sharing algorithm MUST be supported together with the A128GCM authenticated encryption algorithm. Implementations using the A128GCM algorithm MUST ensure that the specific key freshness requirements of the GCM mode are observed (see [NIST-SP-800-38D] Section 8.3). The algorithms corresponding to these identifiers are specified in [I-D.ietf-jose-json-web-algorithms]. 9. Security Considerations The present framework aims to protect the resources on resource servers, the servers themselves, and the services offered. The means proposed to protect these assets is to enforce more granular access restrictions on accessing the devices than all-or-nothing. Due to the setup of the framework, there is also a need to protect the authorization decisions and the keys used to protect the entire resource access procedure. The authorization server is a Trusted Third Party from the point of view of the resource owner, which if compromised could e.g. issue assertions to unauthorized parties or use a bind key to decrypt an eavesdropped GET response secure object payload. In order to enforce a policy decision, the resource server must authenticate the requesting client, and match the identifier of the authenticated entity with the subject identifier of the assertion. As a consequence, in the case of DTLS, the handshake protocol must potentially be executed without knowing that the request will be authorized which opens up for a potential DoS attack. Comparing with authorization using category A identifiers of the access control lists (equivalent to [I-D.ietf-core-coap]), an unauthorized CoAP request masquerading as a legitimate will also not be detected until in the third pass of DTLS handshake. DTLS introduces stateless cookies in ClientHello to prevent DoS attacks. The server having received a ClientHello without cookie from an unverified client sends a HelloVerifyRequest message expecting the client to return ClientHello with a cookie Expires January 6, 2014 [Page 33] INTERNET DRAFT July 5, 2013 corresponding to the parameter values. Only if the cookie can be successfully verified by the server will the DTLS handshake protocol continue. These cookies are unfortunately not very useful in the setting where the client is much more powerful than the server, and the very sending of a HelloVerifyRequest may cost much more than e.g. a verification of a digital signature (e.g. a MAC). If DTLS Handshake is considered a serious threat for DoS, an alternative approach is to carry some lightweight (short and easily computed) keyed integrity information in a TLS extension (TBD) of the ClientHello. Using the established key material, the server can infer with reasonable assurance if a request is legitimate and drop other requests. While DTLS offers bundled encryption and integrity protection of both payload and headers, the object security approach allows for a trade-off between protection against performance. Depending on the trust model, assertion and payload may need to be encrypted because eavesdropping will reveal information about the client's request, which may be privacy sensitive. Wrapping of the payloads as secure objects allows differentiated protection of the content based on its sensitiveness. 10. IANA Considerations TBD: Text about CoAP option numbers (see 4.3). Text about DTLS/TLS extension (see 8.2). Expires January 6, 2014 [Page 34] INTERNET DRAFT July 5, 2013 11. References 11.1 Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf- core-coap-18 (work in progress), June 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2 Informative References [I-D.ietf-lwig-terminology] Bormann, C., Ersue, M., and Keranen, A., "Terminology for Constrained Node Networks", draft-ietf-lwig-terminology-04 (work in progress), April 2013. [SAML] Cantor, S., Kemp, J., Philpott, R., Maler, E., "Assertions and Protocols for the OASIS Security Assertion Markup Language(SAML) V2.0", OASIS, March 2005. [XACML] Rissanen, E., "eXtensible Access Control Markup Language (XACML) Version 3.0", OASIS, September 2012. [SAML-XACML] Rissanen E., and Lockhart H., "SAML 2.0 Profile of XACML , Version 2.0", OASIS, August 2010. [I-D.ietf-oauth-v2-http-mac] Mills, W. and Tschofenig H., Ed., "OAuth 2.0 Message Authentication Code (MAC) Tokens", draft-ietf-oauth-v2- http-mac-03 (work in progress), February 2013. [I-D.ietf-jose-json-web-encryption] Jones, M., Rescorla, E., and Hildebrand J., "JSON Web Encryption (JWE)", draft-ietf-jose-json-web-encryption-11 (work in progress), May 2013. [I-D.ietf-jose-json-web-signature] Jones, M., Bradley, J., and Sakimura N., "JSON Web Signature (JWS)", draft-ietf-jose-json-web-signature-11 Expires January 6, 2014 [Page 35] INTERNET DRAFT July 5, 2013 (work in progress), May 2013. [XMLDSig] Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and Roessler T., "XML Signature Syntax and Processing (Second Edition)", W3C Recommendation, June 2008. [I-D.vial-core-mirror-proxy] Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- proxy-01 (work in progress), July 2012. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf- core-observe-08 (work in progress), February 2013. [I-D.ietf-jose-json-web-algorithms] Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose- json-web-algorithms-11 (work in progress), May 2013. [NIST-SP-800-38D] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", NIST Special Publication 800-38D, November 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS) Authorization Extensions", RFC 5878, May 2010. [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, May 2010. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005. [RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", Expires January 6, 2014 [Page 36] INTERNET DRAFT July 5, 2013 RFC 4279, December 2005. Authors' Addresses Goeran Selander Ericsson Farogatan 6 16480 Kista SWEDEN EMail: goran.selander@ericsson.com Mohit Sethi Ericsson Hirsalantie 11 02420 Jorvas FINLAND EMail: mohit.m.sethi@ericsson.com Ludwig Seitz SICS Swedish ICT AB Scheelevagen 17 22370 Lund SWEDEN EMail: ludwig@sics.se Expires January 6, 2014 [Page 37]