Internet DRAFT - draft-greevenbosch-ace-resource-directory
draft-greevenbosch-ace-resource-directory
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]
