ACE B. Greevenbosch Internet-Draft R. Sun Intended status: Informational Huawei Technologies Expires: June 19, 2015 December 16, 2014 ACE for resource directory draft-greevenbosch-ace-resource-directory-01 Abstract This document describes how ACE can be used to protect the resource directory and allow update and registration to authorised parties only. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 June 19, 2015. Copyright Notice Copyright (c) 2014 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. Greevenbosch & Sun Expires June 19, 2015 [Page 1] Internet-Draft ACE for resource directory December 2014 Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Specifics for the Resource Directory resource . . . . . . . . . 3 4. Registration of Resource Server to Resource Directory . . . . . 5 5. Querying the RD . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Greevenbosch & Sun Expires June 19, 2015 [Page 2] Internet-Draft ACE for resource directory December 2014 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Introduction The document [I-D.ietf-core-resource-directory] defines a resource directory (RD) for Constrained Devices. The RD is used servers to advertise themselves, and by clients to discover those servers. Thus, information in a resource directory is quite valuable. It should therefore be ensured that only authorised parties can access the RD. Especially, servers that have registered themselves with the RD should only be allowed to update their own registrations, and there could be registrictions on which servers can register themselves. Similarly, there may be a requirement to only provide information in the RD to authorised clients, for example when the RD is in a private domain, such as in the case of home automation. This document explores the authorisation and authentication issues associated with resource directories, and describes about how the authentication and authorisation for constrained environments (ACE) work can be applied to protect the RD. It is the intention to treat the RD as a normal CoAP endpoint as much as possible, thereby providing a testdrive for specifications currently being developed in the ACE working group. 3. Specifics for the Resource Directory resource Figure 1 provides a high level overview of a typical RD deployment. The RD is implemented as a CoAP server, whereas CoAP endpoints that query the RD use their CoAP client functionality. Greevenbosch & Sun Expires June 19, 2015 [Page 3] Internet-Draft ACE for resource directory December 2014 +------------+ +------------+ +------------+ | CoAP | | Resource | | CoAP | | Endpoint | Regis- | Directory | | Endpoint | | +--------+ | ter | +--------+ | Query | +--------+ | | | Coap |<---------->| CoAP |<----------->| CoAP | | | | Client | | | | Server | | | | Client | | | +--------+ | | +--------+ | | +--------+ | | ^ | +------------+ | ^ | | : | ^ | | | | : | | | | | | : | v | | | | v | +---------------+ | | | | +--------+ |<----->| Authorisation |<----->| | | | | CoAP | | | Server | | | | | | Server |<--. +---------------+ | | | | +--------+ | | | | | | | .-----------------------------------. | +------------+ +------------+ Figure 1: Resource Directory Deployment In the CoAP architecture, a sensor or actuator is normally implemented as a CoAP server, whereas the endpoint needing to access such sensor or actuator implements a CoAP client. Although not strictly necessary, this could lead to the assumption that in most cases the CoAP server would be the most constrained endpoint. In the RD case, however, the RD is implemented as a CoAP server, but can be expected to be little constrained. The fact that the RD is implemented as a CoAP server leads to the following, highly similar, requirements: REQ-1 The RD should be able to perform authentication and authorisation from a CoAP server's point of view. REQ-2 The RD should be able to authenticate and verify authorisation of CoAP clients. To access an RD, a CoAP endpoint should contain CoAP client functionality. This may or may not be feasible for constrained devices. Hence those constrained devices may need to delegate certain tasks to other endpoints, which implement CoAP client functionality. Those CoAP clients should act on themselves, and may send data (through PUT or POST) to the CoAP server when needed, as well as query the CoAP server's resources (especially .well-known/ core) through GET. We will call those clients delegation clients. The first delegation requirements are as follows: Greevenbosch & Sun Expires June 19, 2015 [Page 4] Internet-Draft ACE for resource directory December 2014 REQ-3 The RD should be able to authenticate and authorise delegation clients. REQ-4 CoAP servers should be able to authenticate and authorise delegation clients. 4. Registration of Resource Server to Resource Directory Registration of an endpoint to the RD is done through a POST, as described in [I-D.ietf-core-resource-directory], section 5.2. During registration, the endpoint provides its identifier, as well as its resources. In addition, it may provide information such as domain, endpoint type, lifetime and context. The context indicates the scheme, ip and port used to access the endpoint. The source of the registration request is considered the default context. When finishing registration, the RD returns location path information for use by the client to update its registration information. The endpoint can update its registration with the RD. This is done through a PUT operation, to the path indicated by the location path in the registration response. The client can update the endpoint type, the lifetime and its context. The endpoint can cancel it registration with the RD through a DELETE operation. Since a constrained server may make use of a delegation client, it does not make sense to require an endpoint be solely able to handle its own registration. Registration has the following requirements for authentication and authorisation: REQ-5 The endpoint should be authenticated, such that it cannot spoof other endpoints, REQ-6 The endpoint should only be able to provide, change or delete registration information of other endpoints if it is authorised to do so. REQ-7 If the endpoint is member of a domain, it should be possible to ensure the true membership of that domain. 5. Querying the RD To Query an RD, a CoAP client sends a CoAP GET request to the RD. The URI indicates the specific directory path, and possibly some queries further defining the requisted information. Greevenbosch & Sun Expires June 19, 2015 [Page 5] Internet-Draft ACE for resource directory December 2014 Since the RD may cater for multiple areas, the directory path can be used to indicate a certain area. For example, an RD for building control may have different areas for handling lights and fire safety equipment. The light may be controlled by the fire safety equipment, whereas the fire safety equipment should not be controlled by the lights. Hence a fire safety device may be provided access to the RD of both the fire safety area and the lighting, whereas a light switch may only be provided access to the RD of the lighting. This leads to the following requirements: REQ-8 The RD should be able to grant different access rights to different clients. REQ-9 If the different areas are implemented through different URIs, it should be possible for the RD to approve or block access to related areas by providing access rights to specific URIs. REQ-10 (TBD) Do we want to specify specific access rights to URI- queries? 6. Architecture This section will give the architecture of using ACE for the resource directory. 7. Solution This section will go into deeper technical details of using ACE for the resource directory. Ideally, the Resource Directory should be treated just like any other CoAP server. 8. Security considerations The complete document concerns security considerations. 9. IANA considerations This document does not require any IANA registrations. 10. References Greevenbosch & Sun Expires June 19, 2015 [Page 6] Internet-Draft ACE for resource directory December 2014 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [I-D.ietf-core-resource-directory] Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource Directory", draft-ietf-core-resource-directory-01 (work in progress), December 2013. Authors' Addresses Bert Greevenbosch Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China Email: bert.greevenbosch@huawei.com Ruinan Sun Huawei Technologies Co., Ltd. Huawei Industrial Base Bantian, Longgang District Shenzhen 518129 P.R. China Email: sunruinan@huawei.com Greevenbosch & Sun Expires June 19, 2015 [Page 7]