CoRE Working Group J. Nieminen, Ed. Internet-Draft B. Patil Intended status: Standards Track T. Savolainen Expires: September 13, 2012 M. Isomaki Nokia Z. Shelby Sensinode C. Gomez Universitat Politecnica de Catalunya/i2CAT M. Ersue Nokia Siemens Networks March 12, 2012 Constrained Application Autoconfiguration draft-nieminen-core-service-discovery-02 Abstract The number and types of devices that are Internet connected continues to grow. Sensors, appliances, utility meters, medical devices etc. are Internet connected for various reasons. Many of these newer devices are constrained in terms of processing power, memory, communication capability and, available power. Devices such as sensors and similar very small devices often lack a proper user interface and hence configuring even the most basic parameters for enabling Internet connectivity on these is extremely difficult. Some of the existing configuration protocols can help in autoconfiguring various parameters of the IP stack needed for Internet connectivity. However this is not sufficient if the devices are using a web service application. There is a need for additional information such as service provider name and username/password etc. for authentication etc. A configuration protocol solution for resource constrained devices is needed in order to enable the potential enabled by Internet connectivity. This document outlines the use cases and requirements for user friendly configuration of such information on a constrained device, and specifies a Constrained Application Protocol (CoAP) based mechanism to meet the requirements. 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- Nieminen, et al. Expires September 13, 2012 [Page 1] Internet-Draft CoAP Autoconfiguration March 2012 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 September 13, 2012. Copyright Notice Copyright (c) 2012 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. Nieminen, et al. Expires September 13, 2012 [Page 2] Internet-Draft CoAP Autoconfiguration March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Use cases and Requirements . . . . . . . . . . . . . . . . . . 5 3. CoAP Based Configuration Discovery and Delivery . . . . . . . 7 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Nieminen, et al. Expires September 13, 2012 [Page 3] Internet-Draft CoAP Autoconfiguration March 2012 1. Introduction Communication via IP over radio links such as 802.15.4 (aka Zigbee) [RFC4944] and Bluetooth Low Energy (BT-LE) [I-D.ietf-6lowpan-btle] have been specified. This has enabled very constrained devices such as sensors and various types of gadgets to become Internet connected. Various types of web services and applications leverage the information and capability of such devices. The 6LoWPAN working group in the IETF has defined an optimized approach to the transmission of IPv6 over low power radio links. Additionally the Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] provides a standard way of implementing web services in a compact manner in environments wherein the device is constrained in terms of processing power, memory, communication capability and, energy. Devices such as sensors or other types of appliances may not have a proper user interface (UI). There may be no display, keyboard, buttons or other ways to interact in order to configure them. Some form of external configuration capability is needed for such devices. The IP stack itself can be autoconfigured via IPv6 stateless autoconfiguration [RFC4862]. However in addition to the IP stack, the application running in the constrained device, such as a CoAP client reporting temperature measurements, needs some amount of configuration. Typically it needs to know at least a (CoAP) servers IP address or a Uniform Resource Locator (URL), and often also the credentials to authenticate with to the server (in the simplest form a username and password). This type of configuration is usually impossible to perform without some kind of user intervention. For instance, the user may need to decide which temperature collection service provider and account to use. Various existing solutions could be considered. Protocols such as DHCP [RFC2131] or Multicast DNS [I-D.cheshire-dnsext-multicastdns] could be used to discover and deliver configuration information within the local domain. Often, devices without a UI, such as Wi-Fi access points or home routers, are configured via a web browser. WiFi APs/routers run a simple web (HTTP) server with a set of HTML forms which are used for configuring them via a browser client from a UI capable device such as computer or tablet. This type of approach to configuration may be very good for many types of devices. It may however not be feasible to support such protocols and mechanisms in the most extremely constrained devices, that have just enough room for a simple CoAP implementation. This document outlines the use cases and requirements for user friendly application configuration for constrained devices. It defines a CoAP based mechanism for automatic configuration discovery and delivery between a constrained device and another host in its Nieminen, et al. Expires September 13, 2012 [Page 4] Internet-Draft CoAP Autoconfiguration March 2012 local network. It also defines a standard format for the basic application configuration information. Finally, it discusses the applicability of this solution, describing the requirements of the environment where it can be securely used. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 1.2. Terminology Constrained device The host that obtains configuration infromation for its application from the helper device. For this purpose it runs a configuration client using CoAP protocol. Helper device The host that provides configuration information for an application on the constrained device. For this purpose it runs a configuration server using CoAP protocol. Configuration client A CoAP client program searching for, fetching and saving the configuration data on the constrained device. Configuration server A CoAP server program having configuration data and responding to the requests sent by configuration clients. 2. Use cases and Requirements The main use cases lie with devices that are sold directly to consumers and are supposed to be able to communicate over the Internet with any service provider of user's choice. This means that the device can't be pre-configured to work with a particular service provider when the consumer purchases it. This is analogous with installing a new IMAP mail client or buying a generic SIP phone. One of the first things the user needs to do is to configure them to work with her chosen service provider. The device could be for instance a Bluetooth Low Energy capable wrist Nieminen, et al. Expires September 13, 2012 [Page 5] Internet-Draft CoAP Autoconfiguration March 2012 unit, that supports some kind of a standard application protocol agreed by the sport wrist vendors, so it could talk to any compliant Internet service. The user would pair it with her smartphone for Internet connectivity. Or, the device could be a temperature sensor connected to a home access point that supports some open temperature reporting protocol supported by more than one service provider. Before these devices can do anything useful, they need information about the service provider and credentials for the user account. One assumption made is that the device is extremely constrained. It uses CoAP as the protocol to communicate with its server, but can't afford to support many additional protocol stacks. For instance, running an HTTP server with HTML forms just for configuration would be impractical. Another assumption is that the consumer has another device at her use that does have a user interface and can be used in the configuration process. For instance, she can have a smartphone or a tablet. In the wrist unit example this is quite clear, as something like a smartphone is used as a router for Internet connectivity. In the home network case, the user would likely have other devices connected to the network via Wi-Fi, for instance. It is assumed that the configuration can be either manually entered or delivered in some way to this helper device. The exact method how tha is done is out of scope of this document, but there are ways such as Short Message Service (SMS) or Open Mobile Alliance Device Management to deliver configuration for mobile phones. It would also be very simple for a service provider to have a website where the user could save the configuration information on the helper device via its browser. If the service provider has a dedicated application, that could be used. Entering the information manually should not be discluded either. After all, this is how many people manage to configure their IMAP accounts. The requirements stemming from the use case and assumptions given are: 1. There must be a way for the configuration client in the constrained device to search and discover whether any of the hosts in its local network running a configuration server that is able provide the client with suitable application configuration information. 2. It must be possible to identify the type of application for which the configuration is valid. (This is to avoid the case where a refridgerator is accidentally given the configuration meant for a coffee machine.) Also, it must be possible to identify the exact device/application instance for which the configuration is valid. Nieminen, et al. Expires September 13, 2012 [Page 6] Internet-Draft CoAP Autoconfiguration March 2012 (This is to deal with cases such as that the user has two similar wrist units, but wants them to use different service providers or user accounts.) 3. It must be possible, after discovery, for the configuration client to fetch the configuration information from the configuration server. 4. It must be possible for the configuration client in the constrained device and the configuration server in the helper device to authenticate and authorize each other, and ensure the confidentiality and integrity of the configuration request and the configuration information transfered between the two. The configuration server should only provide the configuration information for an authenticated and authorized client, and the client should only accept configuration information from an authenticated and authorized server. Authorization may require user interaction. 3. CoAP Based Configuration Discovery and Delivery This Section defines how a constrained device running a configuration client uses CoAP to discover and fetch configuration for a CoAP based application from a helper device running a configuration server. Discovery is based on CoRE link format [I-D.ietf-core-link-format]. To perform discovery, the configuration client sends a CoAP GET request either to the IP address of its default gateway, or to a well known multicast address. The request is targeted to URI /.well- known/core and the Resource Type parameter is set with the value "core-aconf" in the query string. Upon success, the response will contain a link format entry for a suitable configuration formatted in JSON [RFC4627] as recommended in [I-D.bormann-core-links-json]. Implementations MUST support the discovery request to the default gateway, where sending the discovery request to a well known multicast address is seen as OPTIONAL. OPEN ISSUE: It could be possible to contact a configuration outside the local network as well, but that would presumably require some preconfiguration in the client. It is mostly an implementation issue, when exactly the configuration client searches for configuration. It MUST do it when the constrained device is booted up, and the configuration client starts, and it determines it has no existing configuration. It SHOULD do it at start-up also when it does have existing configuration, to check Nieminen, et al. Expires September 13, 2012 [Page 7] Internet-Draft CoAP Autoconfiguration March 2012 if there is a new version available. It SHOULD also do it if the actual CoAP application is not able to connect to its server or access its user account, to make sure configuration is still valid. It is RECOMMENDED that the constrained device also has some kind of a mechanism for the user to explictly ask for a new configuration to be fetched. This could be a physical button or some other procedure. OPEN ISSUE: The query should also contain the application type and potentially a device identifier. How should these be encoded? After the constrained device has received a CoAP response with the link for the configuration information in the payload, it issues a CoAP GET request to the URI in the link to retrieve the actual configuration information. A successful response will include the configuration information in its payload. Basic configuration information contains three pieces: Server IP address, username and password. Only the server IP address is mandatory. The configuration information is encoded in JSON as shown in the example below. 3.1. Example The constrained device searches for an available configuration service and gets a response from a host having that resource: REQ: GET /.well-known/core?rt=core-aconf RES: 2.05 "Content" ;rt="core-aconf" The constrained device then fetches the configuration from the resource it discovered: REQ: GET /config/app RES: 2.05 "Content" [{ address : "host", username : "Foo", pwd : "S.%$"!" }] The value for "host" is interpreted as described in Section 6.1 of [I-D.ietf-core-coap]. If host is provided as an IP-literal or IPv4address, then the server is located at that IP address. If host is a registered name, then that name is considered an indirect Nieminen, et al. Expires September 13, 2012 [Page 8] Internet-Draft CoAP Autoconfiguration March 2012 identifier and the end-point might use a name resolution service, such as DNS, to find the address of that host. 4. Security Considerations NOTE: This section still needs more work. The security considerations described throughout [I-D.ietf-core-coap] apply here as well. User and device specific configuration information is highly sensitive. At least the following types of attacks are possible against the CoAP based configuration mecahnism, unless proper protection is in place: 1. An attacker can reply to configuration client's requests, pretending to be a valid configuration server, and provide the client with false configuration information. This can make the actual application client to connect to a wrong service or a wrong user account. False configuration can also be entered by an active man-in-the-middle with an access to the communication medium and ability to alter messages between the client and the server. 2. An attacker can send out configuration requests and obtain configuration information that it is not supposed to get. With this information, the attacker may be to access user's account for the service the configuration is valid. Congfiguration can also be obtained by a passive eavesdropper with access to the communication medium between the client and the server. To protect against these attacks, the configuration client and server need to have a mechanism to autenticate each other and protect both integrity and confidentiality of the configuration information. There are three approaches that can provide the necessary security, each having their pros and cons: 1. CoAP over DTLS between the configuration client and server. This is the default security mechanism for CoAP, as described in Section 10.1 of [I-D.ietf-core-coap]. The challenge lies with the provision of keys. It is possible to use either pre-shared key, raw public keys, or certificates. It can be assumed that a pre-shared key or client's public key can be set on the server as part of the configuration process. However, setting the pre- shared key or server's public key on the constrained device is more problematic due to its limitations. It may also be Nieminen, et al. Expires September 13, 2012 [Page 9] Internet-Draft CoAP Autoconfiguration March 2012 impractical to have a DTLS stack with X.509 certificate check to be implemented in the types of devices this configuration scheme is targeting to. With client's public key, the server could authenticate the client and communications could be secured. This would still leave it unresolved how the client could authenticate the server. One option is that the constrained device comes pre-configured with some DTLS key just for the configuration purpose, that the user has to keep secret. 2. CoAP over DTLS between the configuration client and server, with additional JSON object security for the configuration information carried as CoAP payload. This differs from the previous option so that the configuration information would be encrypted and signed separately. 3. Link layer security between the constrained device and the helper device. This can be only used in environments where the constrained device is actually directly connected to the helper device over a single link. An example of such environment is an accessory connected to a smartphone over BT-LE. In that case BT- LE's link layer pairing and security mechanism can be applied to authenticate the devices and protect integrity and confidentiality of all communications between them. The initial pairing requires some amount of user interaction, but once it is done, the two devices can securely communicate with each other. What is then needed is a binding from the CoAP/UDP/IP level to the link layer security, so that the configuration client and server know they are communicating over a secure channel. Authentication is based on device identities. 5. IANA Considerations TBD. It may be that some kind of registry to identify the type of applications the configuration is valid needs to be setup. 6. Acknowledgements Salvatore Loreto, Cullen Jennings, Zach Shelby and Zhen Cao have provided comments and support for this work. 7. References Nieminen, et al. Expires September 13, 2012 [Page 10] Internet-Draft CoAP Autoconfiguration March 2012 7.1. Normative References [I-D.bormann-core-links-json] Bormann, C., "Representing CoRE Link Collections in JSON", draft-bormann-core-links-json-00 (work in progress), February 2012. [I-D.ietf-core-coap] Frank, B., Bormann, C., Hartke, K., and Z. Shelby, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-08 (work in progress), October 2011. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-11 (work in progress), January 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. 7.2. Informative References [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-15 (work in progress), December 2011. [I-D.ietf-6lowpan-btle] Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets over Bluetooth Low Energy", draft-ietf-6lowpan-btle-06 (work in progress), March 2012. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. Nieminen, et al. Expires September 13, 2012 [Page 11] Internet-Draft CoAP Autoconfiguration March 2012 Authors' Addresses Johanna Nieminen (editor) Nokia Itaemerenkatu 11-13 FI-00180 Helsinki Finland Email: johanna.1.nieminen@nokia.com Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Teemu Savolainen Nokia Hermiankatu 12 D FI-33720 Tampere Finland Email: teemu.savolainen@nokia.com Markus Isomaki Nokia Keilalahdentie 2-4 FI-02150 Espoo Finland Email: markus.isomaki@nokia.com Zach Shelby Sensinode Hallituskatu 13-17D FI-90100 Oulu Finland Email: zach.shelby@sensinode.com Nieminen, et al. Expires September 13, 2012 [Page 12] Internet-Draft CoAP Autoconfiguration March 2012 Carles Gomez Universitat Politecnica de Catalunya/i2CAT C/Esteve Terradas, 7 Castelldefels 08860 Spain Email: carlesgo@entel.upc.edu Mehmet Ersue Nokia Siemens Networks St.-Martin-Strasse 53 Munich 81541 Germany Email: mehmet.ersue@nsn.com Nieminen, et al. Expires September 13, 2012 [Page 13]