idnits 2.17.1 draft-nieminen-core-service-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-bormann-core-links-json-00 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-11 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-12) exists of draft-ietf-6lowpan-btle-06 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group J. Nieminen, Ed. 3 Internet-Draft B. Patil 4 Intended status: Standards Track T. Savolainen 5 Expires: September 13, 2012 M. Isomaki 6 Nokia 7 Z. Shelby 8 Sensinode 9 C. Gomez 10 Universitat Politecnica de 11 Catalunya/i2CAT 12 M. Ersue 13 Nokia Siemens Networks 14 March 12, 2012 16 Constrained Application Autoconfiguration 17 draft-nieminen-core-service-discovery-02 19 Abstract 21 The number and types of devices that are Internet connected continues 22 to grow. Sensors, appliances, utility meters, medical devices etc. 23 are Internet connected for various reasons. Many of these newer 24 devices are constrained in terms of processing power, memory, 25 communication capability and, available power. Devices such as 26 sensors and similar very small devices often lack a proper user 27 interface and hence configuring even the most basic parameters for 28 enabling Internet connectivity on these is extremely difficult. Some 29 of the existing configuration protocols can help in autoconfiguring 30 various parameters of the IP stack needed for Internet connectivity. 31 However this is not sufficient if the devices are using a web service 32 application. There is a need for additional information such as 33 service provider name and username/password etc. for authentication 34 etc. A configuration protocol solution for resource constrained 35 devices is needed in order to enable the potential enabled by 36 Internet connectivity. This document outlines the use cases and 37 requirements for user friendly configuration of such information on a 38 constrained device, and specifies a Constrained Application Protocol 39 (CoAP) based mechanism to meet the requirements. 41 Status of this Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 13, 2012. 58 Copyright Notice 60 Copyright (c) 2012 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 77 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 78 2. Use cases and Requirements . . . . . . . . . . . . . . . . . . 5 79 3. CoAP Based Configuration Discovery and Delivery . . . . . . . 7 80 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 89 1. Introduction 91 Communication via IP over radio links such as 802.15.4 (aka Zigbee) 92 [RFC4944] and Bluetooth Low Energy (BT-LE) [I-D.ietf-6lowpan-btle] 93 have been specified. This has enabled very constrained devices such 94 as sensors and various types of gadgets to become Internet connected. 95 Various types of web services and applications leverage the 96 information and capability of such devices. The 6LoWPAN working 97 group in the IETF has defined an optimized approach to the 98 transmission of IPv6 over low power radio links. Additionally the 99 Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] provides 100 a standard way of implementing web services in a compact manner in 101 environments wherein the device is constrained in terms of processing 102 power, memory, communication capability and, energy. 104 Devices such as sensors or other types of appliances may not have a 105 proper user interface (UI). There may be no display, keyboard, 106 buttons or other ways to interact in order to configure them. Some 107 form of external configuration capability is needed for such devices. 108 The IP stack itself can be autoconfigured via IPv6 stateless 109 autoconfiguration [RFC4862]. However in addition to the IP stack, 110 the application running in the constrained device, such as a CoAP 111 client reporting temperature measurements, needs some amount of 112 configuration. Typically it needs to know at least a (CoAP) servers 113 IP address or a Uniform Resource Locator (URL), and often also the 114 credentials to authenticate with to the server (in the simplest form 115 a username and password). This type of configuration is usually 116 impossible to perform without some kind of user intervention. For 117 instance, the user may need to decide which temperature collection 118 service provider and account to use. 120 Various existing solutions could be considered. Protocols such as 121 DHCP [RFC2131] or Multicast DNS [I-D.cheshire-dnsext-multicastdns] 122 could be used to discover and deliver configuration information 123 within the local domain. Often, devices without a UI, such as Wi-Fi 124 access points or home routers, are configured via a web browser. 125 WiFi APs/routers run a simple web (HTTP) server with a set of HTML 126 forms which are used for configuring them via a browser client from a 127 UI capable device such as computer or tablet. This type of approach 128 to configuration may be very good for many types of devices. It may 129 however not be feasible to support such protocols and mechanisms in 130 the most extremely constrained devices, that have just enough room 131 for a simple CoAP implementation. 133 This document outlines the use cases and requirements for user 134 friendly application configuration for constrained devices. It 135 defines a CoAP based mechanism for automatic configuration discovery 136 and delivery between a constrained device and another host in its 137 local network. It also defines a standard format for the basic 138 application configuration information. Finally, it discusses the 139 applicability of this solution, describing the requirements of the 140 environment where it can be securely used. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 1.2. Terminology 150 Constrained device 152 The host that obtains configuration infromation for its 153 application from the helper device. For this purpose it runs a 154 configuration client using CoAP protocol. 156 Helper device 158 The host that provides configuration information for an 159 application on the constrained device. For this purpose it runs a 160 configuration server using CoAP protocol. 162 Configuration client 164 A CoAP client program searching for, fetching and saving the 165 configuration data on the constrained device. 167 Configuration server 169 A CoAP server program having configuration data and responding to 170 the requests sent by configuration clients. 172 2. Use cases and Requirements 174 The main use cases lie with devices that are sold directly to 175 consumers and are supposed to be able to communicate over the 176 Internet with any service provider of user's choice. This means that 177 the device can't be pre-configured to work with a particular service 178 provider when the consumer purchases it. This is analogous with 179 installing a new IMAP mail client or buying a generic SIP phone. One 180 of the first things the user needs to do is to configure them to work 181 with her chosen service provider. 183 The device could be for instance a Bluetooth Low Energy capable wrist 184 unit, that supports some kind of a standard application protocol 185 agreed by the sport wrist vendors, so it could talk to any compliant 186 Internet service. The user would pair it with her smartphone for 187 Internet connectivity. Or, the device could be a temperature sensor 188 connected to a home access point that supports some open temperature 189 reporting protocol supported by more than one service provider. 190 Before these devices can do anything useful, they need information 191 about the service provider and credentials for the user account. 193 One assumption made is that the device is extremely constrained. It 194 uses CoAP as the protocol to communicate with its server, but can't 195 afford to support many additional protocol stacks. For instance, 196 running an HTTP server with HTML forms just for configuration would 197 be impractical. 199 Another assumption is that the consumer has another device at her use 200 that does have a user interface and can be used in the configuration 201 process. For instance, she can have a smartphone or a tablet. In 202 the wrist unit example this is quite clear, as something like a 203 smartphone is used as a router for Internet connectivity. In the 204 home network case, the user would likely have other devices connected 205 to the network via Wi-Fi, for instance. It is assumed that the 206 configuration can be either manually entered or delivered in some way 207 to this helper device. The exact method how tha is done is out of 208 scope of this document, but there are ways such as Short Message 209 Service (SMS) or Open Mobile Alliance Device Management to deliver 210 configuration for mobile phones. It would also be very simple for a 211 service provider to have a website where the user could save the 212 configuration information on the helper device via its browser. If 213 the service provider has a dedicated application, that could be used. 214 Entering the information manually should not be discluded either. 215 After all, this is how many people manage to configure their IMAP 216 accounts. 218 The requirements stemming from the use case and assumptions given 219 are: 221 1. There must be a way for the configuration client in the 222 constrained device to search and discover whether any of the 223 hosts in its local network running a configuration server that is 224 able provide the client with suitable application configuration 225 information. 227 2. It must be possible to identify the type of application for which 228 the configuration is valid. (This is to avoid the case where a 229 refridgerator is accidentally given the configuration meant for a 230 coffee machine.) Also, it must be possible to identify the exact 231 device/application instance for which the configuration is valid. 233 (This is to deal with cases such as that the user has two similar 234 wrist units, but wants them to use different service providers or 235 user accounts.) 237 3. It must be possible, after discovery, for the configuration 238 client to fetch the configuration information from the 239 configuration server. 241 4. It must be possible for the configuration client in the 242 constrained device and the configuration server in the helper 243 device to authenticate and authorize each other, and ensure the 244 confidentiality and integrity of the configuration request and 245 the configuration information transfered between the two. The 246 configuration server should only provide the configuration 247 information for an authenticated and authorized client, and the 248 client should only accept configuration information from an 249 authenticated and authorized server. Authorization may require 250 user interaction. 252 3. CoAP Based Configuration Discovery and Delivery 254 This Section defines how a constrained device running a configuration 255 client uses CoAP to discover and fetch configuration for a CoAP based 256 application from a helper device running a configuration server. 258 Discovery is based on CoRE link format [I-D.ietf-core-link-format]. 259 To perform discovery, the configuration client sends a CoAP GET 260 request either to the IP address of its default gateway, or to a well 261 known multicast address. The request is targeted to URI /.well- 262 known/core and the Resource Type parameter is set with the value 263 "core-aconf" in the query string. Upon success, the response will 264 contain a link format entry for a suitable configuration formatted in 265 JSON [RFC4627] as recommended in [I-D.bormann-core-links-json]. 267 Implementations MUST support the discovery request to the default 268 gateway, where sending the discovery request to a well known 269 multicast address is seen as OPTIONAL. 271 OPEN ISSUE: It could be possible to contact a configuration outside 272 the local network as well, but that would presumably require some 273 preconfiguration in the client. 275 It is mostly an implementation issue, when exactly the configuration 276 client searches for configuration. It MUST do it when the 277 constrained device is booted up, and the configuration client starts, 278 and it determines it has no existing configuration. It SHOULD do it 279 at start-up also when it does have existing configuration, to check 280 if there is a new version available. It SHOULD also do it if the 281 actual CoAP application is not able to connect to its server or 282 access its user account, to make sure configuration is still valid. 283 It is RECOMMENDED that the constrained device also has some kind of a 284 mechanism for the user to explictly ask for a new configuration to be 285 fetched. This could be a physical button or some other procedure. 287 OPEN ISSUE: The query should also contain the application type and 288 potentially a device identifier. How should these be encoded? 290 After the constrained device has received a CoAP response with the 291 link for the configuration information in the payload, it issues a 292 CoAP GET request to the URI in the link to retrieve the actual 293 configuration information. A successful response will include the 294 configuration information in its payload. 296 Basic configuration information contains three pieces: Server IP 297 address, username and password. Only the server IP address is 298 mandatory. The configuration information is encoded in JSON as shown 299 in the example below. 301 3.1. Example 303 The constrained device searches for an available configuration 304 service and gets a response from a host having that resource: 306 REQ: GET /.well-known/core?rt=core-aconf 308 RES: 2.05 "Content" 309 ;rt="core-aconf" 311 The constrained device then fetches the configuration from the 312 resource it discovered: 314 REQ: GET /config/app 316 RES: 2.05 "Content" 317 [{ address : "host", 318 username : "Foo", 319 pwd : "S.%$"!" 320 }] 322 The value for "host" is interpreted as described in Section 6.1 of 323 [I-D.ietf-core-coap]. If host is provided as an IP-literal or 324 IPv4address, then the server is located at that IP address. If host 325 is a registered name, then that name is considered an indirect 326 identifier and the end-point might use a name resolution service, 327 such as DNS, to find the address of that host. 329 4. Security Considerations 331 NOTE: This section still needs more work. 333 The security considerations described throughout [I-D.ietf-core-coap] 334 apply here as well. 336 User and device specific configuration information is highly 337 sensitive. At least the following types of attacks are possible 338 against the CoAP based configuration mecahnism, unless proper 339 protection is in place: 341 1. An attacker can reply to configuration client's requests, 342 pretending to be a valid configuration server, and provide the 343 client with false configuration information. This can make the 344 actual application client to connect to a wrong service or a 345 wrong user account. False configuration can also be entered by 346 an active man-in-the-middle with an access to the communication 347 medium and ability to alter messages between the client and the 348 server. 350 2. An attacker can send out configuration requests and obtain 351 configuration information that it is not supposed to get. With 352 this information, the attacker may be to access user's account 353 for the service the configuration is valid. Congfiguration can 354 also be obtained by a passive eavesdropper with access to the 355 communication medium between the client and the server. 357 To protect against these attacks, the configuration client and server 358 need to have a mechanism to autenticate each other and protect both 359 integrity and confidentiality of the configuration information. 361 There are three approaches that can provide the necessary security, 362 each having their pros and cons: 364 1. CoAP over DTLS between the configuration client and server. This 365 is the default security mechanism for CoAP, as described in 366 Section 10.1 of [I-D.ietf-core-coap]. The challenge lies with 367 the provision of keys. It is possible to use either pre-shared 368 key, raw public keys, or certificates. It can be assumed that a 369 pre-shared key or client's public key can be set on the server as 370 part of the configuration process. However, setting the pre- 371 shared key or server's public key on the constrained device is 372 more problematic due to its limitations. It may also be 373 impractical to have a DTLS stack with X.509 certificate check to 374 be implemented in the types of devices this configuration scheme 375 is targeting to. With client's public key, the server could 376 authenticate the client and communications could be secured. 377 This would still leave it unresolved how the client could 378 authenticate the server. One option is that the constrained 379 device comes pre-configured with some DTLS key just for the 380 configuration purpose, that the user has to keep secret. 382 2. CoAP over DTLS between the configuration client and server, with 383 additional JSON object security for the configuration information 384 carried as CoAP payload. This differs from the previous option 385 so that the configuration information would be encrypted and 386 signed separately. 388 3. Link layer security between the constrained device and the helper 389 device. This can be only used in environments where the 390 constrained device is actually directly connected to the helper 391 device over a single link. An example of such environment is an 392 accessory connected to a smartphone over BT-LE. In that case BT- 393 LE's link layer pairing and security mechanism can be applied to 394 authenticate the devices and protect integrity and 395 confidentiality of all communications between them. The initial 396 pairing requires some amount of user interaction, but once it is 397 done, the two devices can securely communicate with each other. 398 What is then needed is a binding from the CoAP/UDP/IP level to 399 the link layer security, so that the configuration client and 400 server know they are communicating over a secure channel. 401 Authentication is based on device identities. 403 5. IANA Considerations 405 TBD. It may be that some kind of registry to identify the type of 406 applications the configuration is valid needs to be setup. 408 6. Acknowledgements 410 Salvatore Loreto, Cullen Jennings, Zach Shelby and Zhen Cao have 411 provided comments and support for this work. 413 7. References 414 7.1. Normative References 416 [I-D.bormann-core-links-json] 417 Bormann, C., "Representing CoRE Link Collections in JSON", 418 draft-bormann-core-links-json-00 (work in progress), 419 February 2012. 421 [I-D.ietf-core-coap] 422 Frank, B., Bormann, C., Hartke, K., and Z. Shelby, 423 "Constrained Application Protocol (CoAP)", 424 draft-ietf-core-coap-08 (work in progress), October 2011. 426 [I-D.ietf-core-link-format] 427 Shelby, Z., "CoRE Link Format", 428 draft-ietf-core-link-format-11 (work in progress), 429 January 2012. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 [RFC4627] Crockford, D., "The application/json Media Type for 435 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 437 7.2. Informative References 439 [I-D.cheshire-dnsext-multicastdns] 440 Cheshire, S. and M. Krochmal, "Multicast DNS", 441 draft-cheshire-dnsext-multicastdns-15 (work in progress), 442 December 2011. 444 [I-D.ietf-6lowpan-btle] 445 Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., 446 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 447 over Bluetooth Low Energy", draft-ietf-6lowpan-btle-06 448 (work in progress), March 2012. 450 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 451 RFC 2131, March 1997. 453 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 454 Address Autoconfiguration", RFC 4862, September 2007. 456 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 457 "Transmission of IPv6 Packets over IEEE 802.15.4 458 Networks", RFC 4944, September 2007. 460 Authors' Addresses 462 Johanna Nieminen (editor) 463 Nokia 464 Itaemerenkatu 11-13 465 FI-00180 Helsinki 466 Finland 468 Email: johanna.1.nieminen@nokia.com 470 Basavaraj Patil 471 Nokia 472 6021 Connection drive 473 Irving, TX 75039 474 USA 476 Email: basavaraj.patil@nokia.com 478 Teemu Savolainen 479 Nokia 480 Hermiankatu 12 D 481 FI-33720 Tampere 482 Finland 484 Email: teemu.savolainen@nokia.com 486 Markus Isomaki 487 Nokia 488 Keilalahdentie 2-4 489 FI-02150 Espoo 490 Finland 492 Email: markus.isomaki@nokia.com 494 Zach Shelby 495 Sensinode 496 Hallituskatu 13-17D 497 FI-90100 Oulu 498 Finland 500 Email: zach.shelby@sensinode.com 501 Carles Gomez 502 Universitat Politecnica de Catalunya/i2CAT 503 C/Esteve Terradas, 7 504 Castelldefels 08860 505 Spain 507 Email: carlesgo@entel.upc.edu 509 Mehmet Ersue 510 Nokia Siemens Networks 511 St.-Martin-Strasse 53 512 Munich 81541 513 Germany 515 Email: mehmet.ersue@nsn.com