idnits 2.17.1 draft-vasu-core-ace-service-provisioning-00.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 (Oct 19, 2015) is 3112 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) -- Obsolete informational reference (is this intentional?): RFC 6347 (ref. 'DTLS') (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Vasu K 3 INTERNET-DRAFT Rahul A J 4 Intended Status: Standard Track Yangneng 5 Expires: April 19, 2016 Huawei 6 Oct 19, 2015 8 Service Provisioning for Constrained Devices 9 draft-vasu-core-ace-service-provisioning-00 11 Abstract 13 As more constrained devices are integrating with current Internet, 14 the ubiquitous computing in scenarios like smart home is very 15 important. In smart home, the constrained devices (ex. thermostat) 16 need to be provisioned in such a way that it can inter-operate with 17 any kind of devices like other constrained devices (ex. Air 18 conditioner) or client devices (ex. smart phone). This document 19 provides a method to support service provisioning based on pre- 20 configured admission and resource control policies, where this method 21 explains device's service access in two different use cases: first 22 provisioning the service when a constrained device accessing the 23 service provided by other constrained device, second, accessing the 24 service provided by constrained device from the client device (non 25 constrained device). 27 Status of this Memo This Internet-Draft is submitted to IETF in full 28 conformance with the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on April 19, 2016. 48 Copyright and License Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4 System Architecture . . . . . . . . . . . . . . . . . . . . . . 6 69 5 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 6.1 Register Service . . . . . . . . . . . . . . . . . . . . . . 10 72 6.3.1 Resource Control . . . . . . . . . . . . . . . . . . . . 14 73 6.4 Search for services by device . . . . . . . . . . . . . . . 18 74 6.5 Service request and response . . . . . . . . . . . . . . . . 18 75 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 22 76 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22 77 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 78 9.1 Normative References . . . . . . . . . . . . . . . . . . . 23 79 9.2 Informative References . . . . . . . . . . . . . . . . . . 23 80 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 83 1 Introduction 85 The work on Constrained Restful Environment (CoRE) aimed to realize 86 the restful architecture for constrained devices [RFC7228] in 87 constrained networks [RFC4944]. The CORE work group has recently 88 standardized constrained application protocol (CoAP) [RFC7252] for 89 interacting with constrained resources where general HTTP is not 90 memory/energy efficient. The use of web linking for resources 91 description and discovery hosted by constrained web servers is 92 specified by CORE [RFC6690]. Even though, CoAP allows the direct 93 resource access for constrained devices, it is not advisable for 94 direct access of resources in networks where multicast procedures are 95 infeasible due to heavy network load, and the networks where sleepy 96 nodes exist. So, the CoRE working group comes up with a solution 97 called resource directory (RD) [draft-ietf-core-resource-directory] 98 to host the devices service information, and allow other devices to 99 perform lookup procedures through .well-known/core path to resources. 101 The services advertised by these constrained devices needs to be 102 commissioned and provisioned properly to allow other devices to 103 access it. CoRE RD solution is a directory based solution that 104 depends on CoAP protocol. CORE RD solution uses 105 registration/update/delete/lookup procedures for service 106 registration, service update, deleting service, lookup of services 107 respectively. Service commissioning is a method which verifies a pre 108 registered services with special commissioning tools/agents. These 109 tools can be tablets or special embedded devices which initially 110 stores the devices identifications in secure manner. Once the 111 services are advertised by any device, those services need to be 112 verified using commissioner. CORE RD provides a standard procedure to 113 interact with commissioner, where commissioner acts like a client 114 device to look up and verify the advertised services. Once the 115 commissioner verifies the pre-registered services, commissioner can 116 put some policy rules on services hosted by devices for resource 117 control. These rules defined on (1) how to access the services either 118 with other constrained devices or client devices, and (2) on 119 operational instructions. 121 Architecture is defined to authenticate and authorize client requests 122 for a resource on a server using logical entities such as client(C), 123 client authorization manager(CAM), server(S), and server 124 authorization manager(SAM)[draft-gerdes-ace-actors]. The main goal of 125 delegated CoAP authentication and authorization framework (DCAF) is 126 the setup of a datagram transport layer security channel between two 127 nodes to securely transmit authorization tickets [draft-gerdes- 128 core-dcaf-authorize]. The CAM sends an access request message on 129 behalf of client by embedding requested permissions in client 130 authorization information (CAI) field of access request message to 131 SAM. A ticket grant message is sent from SAM by embedding the 132 permissions given from the server on a specific resource in server 133 authorization information (SAI) field of ticket grant message to the 134 client. These SAI, CAI use authorization information format (AIF) 135 that describes the permissions requested from access request in a 136 ticket request, where the underlying access control model will be 137 that of an access matrix, which gives a set of permissions for each 138 possible combination of a subject and an object [draft-bormann-core- 139 ace-aif]. This simple information model also doesn't allow 140 conditional access (e.g.,"resource /s/tempC is accessible only if 141 client belongs to group1 and does not belong to group2"). Finally, 142 the model does not provide any dynamic functions such as enabling 143 special access for a set of resources that are specific to a subject. 144 But, the services provided by resources in constrained environment, 145 need to be authorized and controlled conditionally based on some 146 service level agreements or preconfigured policies on resource 147 control. 149 Considering an example use case scenario such as thermostat device 150 measures the current room temperature, and can service for air 151 conditioner device to set automatic temperatures. In a smart home, 152 user wants to regulate his room temperature automatically using his 153 airconditioner device. Here, this airconditioner device can adjust 154 its temperature to either cool the room or heat the room by accessing 155 the service provided by the thermostat. Suppose this user leaves the 156 home in the morning in hot summer and leaves the office in the 157 evening to reach to home. But, before he reaches his room he wants to 158 make his room cool enough. So he has to switch on the airconditioner 159 from his mobile one hour before he leaves the office. So, before 160 adjusting his aircconditioner to make the room cool enough, he might 161 have to know the current room temperature. Thus he access the service 162 provided by the thermostat to read the room temperature and adjust 163 the airconditioner. However, there is a problem here on how to access 164 these services which are provided by user's home devices itself, what 165 is the authenticity level to access from outside the home, even 166 within home what is the access control/resource control of these 167 devices because the neighboring device which are not authenticated 168 can also access these service if those devices are within the 169 constrained network range. Finally it is important to admit access of 170 the service by client based on the configuration policies so that the 171 devices can be protected from hazardous conditions, and allows only 172 pre-agreed operations on devices. 174 The service provisioning presented in this document provides a method 175 to support admission, and resource control policies using 176 commissioning procedure. The method explains the device's service 177 access in two different use cases: first provisioning the service 178 when a constrained device accessing the service provided by other 179 constrained device, second, accessing the service provided by 180 constrained device from the client device. Even though it is out of 181 scope of the present document, it also considers a secure way of 182 service commissioning as part of security. 184 2 Motivation 186 CORE RD solution provides various automated operations such as 187 service registrations, service update, service removal, and service 188 lookups initiated by endpoints and clients. However, managing this 189 centralized directory server by allowing authorized users to perform 190 these tasks, setting some service level agreements on clients to 191 access these services, and providing limited or scope oriented 192 lookups by other endpoints or clients require efficient service 193 provisioning mechanism. The service provisioning method presented in 194 this document deals on how a registered service from devices can be 195 accessed by various clients or other devices. Moreover, it also 196 provides a method for handling this resource/service access control 197 mechanism using web service model for efficient service provisioning 198 from outside the constrained home environment. 200 3 Terminology 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 o "CORE", CORE is a Constrained RESTful Environment providing a 207 framework for resource-oriented application intended to run on 208 constrained networks [RFC7228]. 210 o "COAP" The Constrained Application Protocol (CoAP) is a 211 specialized web transfer protocol for use with constrained nodes 212 and networks [RFC7252]. 214 o "RD" The Resource Directory (RD) is a directory based server to 215 host the descriptions of resources and allowing the lookups to be 216 performed for those resources by various client devices. 218 o "Commissioner" Commissioning agent is tool/device that verifies 219 the devices operation, integrity check with the network. 221 o "Constrained Device" These are embedded computing devices that 222 are expected to be as resource constrained in terms of RAM/ROM 223 size, and to be deployed with the constrained environment such as 224 6LoWPAN Networks. 226 o "Client" A client device is like resource constrained client 227 such as other constrained device (ex. Air conditioner) or rich 228 client devices such as Mobile/Laptop/Tablet etc, which access the 229 services hosted by constrained devices (ex. thermostat). 231 o "Provisioning Server" this server is a process of verifying 232 service requester, providing access controls or admission controls 233 on resources to be accessed and inter-operating with various 234 devices without bothering about kind of network protocols used. It 235 also provides web access model outside the constrained 236 environment. 238 o "Device Profile" A device profile comprises a set of attributes 239 that are associated with a particular device. These include 240 services, features, names, descriptions etc. 242 4 System Architecture 244 The system architecture is better explained with two different 245 scenarios: (1) Constrained device access the service advertised by 246 other constrained device is as shown in Fig 1. Here, one 247 constrained device such as air-conditioner can access the service 248 such as current room temperature advertised by other constrained 249 device (ex. thermostat). This advertised service is to be 250 commissioned by commissioner, and then it should be set with some 251 admission and resource control policies by provisioning server. 252 And, finally the service is allowed to advertise its service 253 access from other constrained devices. Any device that is 254 interested in that advertised service, need to do service lookup 255 from RD Server. Once obtaining the path to the advertised service, 256 the constrained client device can request a service to the 257 device which hosts the service. Before sending the request, it 258 MUST establish a secure channel between these two nodes [draft- 259 schmitt-ace-twowayauth-for-iot]. Once the incoming request comes 260 from the constrained client device, the device which hosts the 261 service MUST authorize and provision for conditional access of its 262 service from the provisioning server. The notification regarding 263 the registered services to the commissioning agent can be sent 264 from the RD server, which can be implementation specific and left 265 for the user to choose any standard procedures and is out of scope 266 of present document. Detailed operational procedure will be 267 explained in the later sections of this document. 269 +------+ +-------+ +-----+ +--------+ +----------+ 270 |Device1 |Device2| | RD | |Provis | |Commision 271 |(Air |(Thermo| | | |ioning | |ing | 272 |Condi | | stat)| |Serv |Sever | |Agent | 273 |tioner) | | |er | | | | | 274 +--|---+ +----|--+ +--|--+ +----|---+ +-----|----+ 275 | | | | | 276 | | | | | 277 | |Register | | | 278 | ----------// | | 279 | | Service/| Verify Preregistered\ |/ 280 | | ------------------------// 281 | | | Service| // | 282 | | | | / | 283 | | | | | 284 | | | | | 285 | | | | | 286 | | | |//Define | 287 | | | /------------- 288 | | | / \ Policies | 289 |Search a Service \ | | | 290 ---------------------// | | 291 | | //| | | 292 | | / | | | 293 | | | | | 294 | | | | | 295 |Request | | | | 296 -----------/ | | | 297 |Service /| | | | 298 | / | | | | 299 | |Check for authorization | 300 | |admission, Resource | | 301 | ---------------------// | 302 | | Control Policies //| | 303 | | | / | | 304 | | | | | 305 | | | | | 306 | | // Service Grant/Deny | 307 | /--------------------- | 308 | /|\ | | | 309 | / | | | | 310 \//Service | | | | 311 /\---------- | | | 312 | Grant/Deny | | | 313 | | | | | 315 Fig 1.Constrained device accessing service from constrained device 316 +--------+ +-------+ +-------+ +---------+ +---------+ 317 |Client | |Device2| |RD | |Provision| |Commissi | 318 |(Smart | |(Thermo| |Server | |ing Server |oning | 319 | Phone) | | stat) | | | | | |Agent | 320 | | | | | | | | | | 321 | | | | | | | | | | 322 +---|----+ +---|---+ +---|---+ +----|----+ +-----|---+ 323 | | | | | 324 | | | | | 325 | |Register | | | 326 | -----------/ | | 327 | |Service / | | 328 | | /| | | 329 | | | / | | 330 | | |//Verify Preregistered | 331 | | -------------------------- 332 | | |\ Service | 333 | | | | | 334 | | | | | 335 | | | | / | 336 | | | |//Define | 337 | | | ------------- 338 | | | |\ Policies | 339 | | | | | 340 | Request for Service | \ | 341 ----------------------------------// | 342 | | | //| | 343 | | | / | | 344 | | | | | 345 | | / | | | 346 | |// Request| for Service | 347 | ----------------------- | 348 | | | | | 349 | | | | | 350 | | | | | 351 | | Service Grant/Deny\ | | 352 | ----------------------/ | 353 | | | //| | 354 | | | / | | 355 | | | | | 356 | | | | | 357 | // | | | | 358 |// Service Grant/Deny | | 359 \---------------------------------- | 360 | \ | | | | 361 | | | | | 363 Fig 2. Client accessing service from Constrained device 365 2) Client device access the service advertised by constrained 366 device is as shown in Fig 2. For example, the client device such 367 as smart phone can access the service (ex. room temperature) 368 advertised by other constrained device (ex. thermostat). The 369 client can access the service within a home environment or outside 370 the home environment. So, in this scenario, the provisioning 371 server maintains the service as a web service. 373 This advertised service is to be commissioned by commissioner, 374 then to be set with some admission and resource control policies 375 by provisioning server. And, finally the service is allowed to 376 advertise its access from the client devices. Any client that 377 wishes to access this web service looks for corresponding 378 operations provided from the provisioning server. 380 5 Network Topology 382 The constrained devices such as Thermostat, Airconditioner may use 383 small memory constrained sensors/actuators for simple services 384 such as cooling/heating the room or just to measure the current 385 room temperature. These memory constrained embedded devices may 386 implement the 6LoWPAN stack such as uIP (provided by Contiki), and 387 provide access for communication to other external queries from 388 client devices such as smart phone which typically implements rich 389 stack TCP/IP. Even though RD server or Provisioning server are 390 shown as separate servers in the LAN as given in Fig 3, these can 391 be hosted on a single server running two different processes. 392 Moreover, the commissioner implements a standard procedure to 393 interact with devices as a separate agent process which is out of 394 scope of the present document and has been left to user's choice 395 while satisfying the mentioned operations in the current draft. On 396 the other hand, these specific operations can be implemented 397 separately as a third party and to be used at the commissioning 398 agent. The lower level communication technology can be implemented 399 either through Bluetooth (BT) or near field communication (NFC) to 400 verify the devices unique ID (for ex. using MAC). Even though, the 401 implementation procedure for commissioner is out of scope for the 402 present document, it is shown as sample interaction with RD 403 server/provisioning server as part of commissioning procedure in 404 subsequent sections. Even though the present document discusses 405 about 6LoWPAN based sensor network, it can be easily moved to any 406 other technology such as Zigbee/BLE/Wireless HART without any 407 changes in the architecture or design, because the present 408 document abstracted the communication networks with their edge 409 routers. The communication and routing mechanisms or procedure 410 between edge router and sensor devices/client devices are out of 411 scope of the present document. 413 ------- -------- 414 // \ // \ 415 / // \ 416 / / 417 / / 418 | +--------+ | | +--------+| 419 | |RD Server---| | | +-----+ |Thermostat| 420 | +--------+ | | LAN | |Edge | +--------+ | 421 | |------|------- | | 422 | +----------+ | | | | |Router 6LoWPAN | 423 | |Provision --|| | |+-----+ | 424 |Server | / | +--------+ / 425 +----------+ / | |Aircondioner 426 / | \ +--------+// 427 \ // | \ // 428 ------- | -------- 429 | 430 | 431 | 432 | 433 | 434 -|----- 435 //- | -\ 436 // +-|----+ \ 437 / |Edge | 438 / |Router| 439 | +------+ | 440 | | 441 | WiFi | 442 | +-------+ +-----+ | 443 | |Smart | |Commisioning 444 | |Phone | | Agent| 445 +-------+ +-----+/ 446 / 447 \ // 448 \- -// 449 ------- 451 Fig 3. Network Topology 453 6 Operations 455 6.1 Register Service 457 The constrained device which hosts the service MUST register its 458 service with the RD server using its unique identifier (for ex. 459 MAC id, UDDI registry etc.) and IP address as shown in Fig 4. The 460 device MUST send a POST request for registering its service. 462 Before sending a request, it MUST establish a secure channel 463 between these two nodes [draft-schmitt-ace-twowayauth-for-iot]. 464 Once the service has been registered with the RD server, the RD 465 server may notify the registered information of a device (for 466 ex.its unique identifier and device name) to a commissioning 467 agent. 469 +---------+ +---------+ 470 | | | | 471 | Device | |RD Server| 472 | | | | 473 +----+----+ +-----+---+ 474 | | 475 | | 476 | `. | 477 | POST /rd?ep=node1&d=example.com&et=temperature-no`.| 478 +--------------------------------------------------,'. 479 | gp=thermostat&con=DeviceID(100) ,' | 480 | ,' | 481 | ,' | 482 | ,' 2.01 Created Location: /rd/7521 | 483 `.---------------------------------------------------- 484 | `-. | 485 | `. | 486 | | 488 Fig. 4 Registering a Service 490 6.2 Verify pre-registered service 492 The commissioning agent MUST verify any pre registered service 493 with the RD server as shown in Fig 5. The commissioning agent 494 sends a GET request for domain lookup. Before sending the request, 495 it MUST establish a secure channel between these two nodes 496 [DTLS][TLS]. Once obtaining the specific domain, it MUST look for 497 the group to which the service belongs. Once obtaining the 498 specific domain and group, it MUST send a service look up with the 499 RD server for the registered service. Once obtaining the service 500 information about a specific device, the commissioning agent MUST 501 verify the registered service. This service information is later 502 used to create service registry in the provisioning server as 503 explained in the following section. The example service 504 information (denoted as SRV) looks like as shown in Fig 6. 506 +---------------+ +----------+ 507 |Commissioning | | RD Server| 508 |Agent | | | 509 +------+--------+ +--------+-+ 510 | | 511 | | 512 | GET /rd-lookup/d `. | 513 +--------------------------------------------------:'. 514 | .' | 515 | | 516 | .'2.05 Content ;d=example.com,;d=example.com 517 ::---------------------------------------------------+ 518 | `-. | 519 | GET /rd-lookup/gp?ep=node1&d=example.com `. | 520 +---------------------------------------------------/. 521 | .' | 522 | | 523 | .'2.05 Content ;gp=thermostat;ep=node1 524 ::---------------------------------------------------+ 525 | `-. | 526 | `. | 527 | GET /rd-lookup/res?rt=temp&gp=thermostat&d=example.com 528 +--------------------------------------------------:'. 529 | .' | 530 | | 531 | .'2.05 Content ;rt=temp;gp=thermostat 532 ::---------------------------------------------------+ 533 | `-. d=example.com | 534 +---------------------------+ | 535 |Authentication of Service | | 536 |Info and DeviceID | | 537 +---------------------------+ POST Verified User; DeviceID`. | 538 +---------------------------------------------------:: 539 | .' .-' | 540 .`.__________________________________________________| 541 | `. 2.00 OK | 543 Fig. 5 Verify pre registered service 545 SRV { 546 Name: Node1 547 Group: Thermostat 548 Domain: myhome.com 549 Type: Temperature node 550 Device ID: 1001 551 Device IP: 552 } 553 Fig 6. Example Service Informaion 555 6.3 Define policies on resource control 557 +----------------+ +---------------+ 558 |Commissioning | |Provisioning | 559 | Agent | | Server | 560 +------+---------+ +--------+------+ 561 | POST /thermostat /HTTP/1.1 `. | 562 +------------------------------------------/. 563 | HOST thermostat.ps.example.com .' | 564 | Content-Type: application/text | 565 | SRV { Name: Node1 | 566 | Group: Thermostat | 567 | Domain: myhome.com | 568 | Type: Temperature-node | 569 | DeviceID: 1001 | 570 | DeviceIP: } | 571 | | 572 | .' HTTP/1.1 200 OK | 573 ::------------------------------------------' 574 | `. Content-Type: application/text | 575 | { sID (service ID) } | 576 | | 577 | POST /thermostat /HTTP/1.1 `. | 578 +------------------------------------------:: 579 | HOST thermostat.ps.example.com .' | 580 | Content-Type: application/text | 581 | AC { ServiceID: 1234 | 582 | Auth: Basic Auth Support | 583 | Count: 10 | 584 | Admission Control: R,W,R/W,D } | 585 | | 586 | .' HTTP/1.1 200 OK | 587 ::------------------------------------------+ 588 | `. Content-Type: application/text | 589 | | 590 | POST /thermostat /HTTP/1.1 `. | 591 +------------------------------------------:: 592 | HOST thermostat.ps.example.com .' | 593 | Content-Type: application/text | 594 | RC { If C is from G1 allow {R,W}; | 595 | If C is from G2&!G3 allow {R}; | 596 | If C is from d1&g1 allow {R,W,D}; | 597 | : } | 598 | .' HTTP/1.1 200 OK | 599 ::------------------------------------------+ 600 | `. Content-Type: application/text | 601 | | 602 Fig. 7 Defining Policies on Resource and Access Control 604 Once the hosted service has been verified by commissioning agent 605 (CA), the CA MUST create a service registry with the provisioning 606 server as explained in Fig 7. The provisioning server SHOULD send 607 a service ID as a response back to the commissioning agent after 608 creating the service entry. 610 This service ID can be later used by the commissioning agent to 611 permanently DELETE the service entry ( if required). The 612 commissioning agent MUST create some admission control policies 613 such as read (R), write (W), read/write (R/W), delete (D), number 614 of simultaneous connection on resource etc. on the registered 615 service. Once the admission control policies has been set on a 616 specific device, the resource control policies such as conditional 617 access of a service, quality of service agreements (based on the 618 priority levels set for clients) can be set on that registered 619 service. These conditional access on service can be implemented 620 with simple conditional statements as explained in section 6.3.1 621 (for ex. "client (c) can access service with only read (R), write 622 (W) permissions if it only belongs to group (g)"). The 623 implementation or information format details of these conditional 624 statements is out of scope of the present document (TBD). The 625 example admission control and resource control policies are as 626 shown in Fig 8, and Fig 9 respectively. 628 AC { 629 Service ID: 12345 630 Auth: Basic Auth Support 631 Count: 10 632 Admission Control: R, W, R/W, D 633 : 634 : 635 } 637 Fig 8. Example Admission Control Policies 639 RC { 640 If c is from g1 allow {R,W} 641 If C is from g2 & !g3 {R} 642 If C is from d1 & g1 allow {R, W, D} 643 : 644 : 645 } 647 Fig 9. Example Resource Control Policies 649 6.3.1 Resource Control 651 Resource control policies for constrained devices are expressed in 652 terms of conditional expressions as explained in Fig. 9. Consider 653 a scenario where we define the client (C) (who accesses the 654 resource) in terms of groups/levels. For example in a typical home 655 building, we assign each floor as a group. Suppose for a three 656 floor building, the clients such as mobile phone/air conditioner 657 can belong to any of the floor within a building. And we allow 658 various permissions for the clients according to the group it 659 belongs to, as specified in Fig 10. 661 --------------------------- 662 | | | | | | 663 |Client | R | W | U | D | 664 |-------------|---|---|---| 665 |G1 | * | - | * | - | 666 | | | | | | 667 |G2 | * | * | - | - | 668 | | | | | | 669 |G3 | - | - | - | * | 670 |-------------------------- 671 Fig 10. Example Permissions on Methods 673 Supposed we assigned the priorities for different groups as C 674 belongs to {G1, G2, G3} => {P1, P3, P2}. Moreover, if we would 675 like to assign different QoS classes for clients, depending on the 676 applications they use then it is required to control QoS policies 677 in resource control. QoS is defined in terms of various parameters 678 such as {availability, reliability, serviceability, data accuracy, 679 aggregation delay, coverage, fault tolerance, network lifetime} in 680 wireless sensor networks. It is assumed that based on these 681 parameters, QoS is defined in terms of various classes such as 682 {Q1, Q2, Q3}, then it is required that some of the clients can 683 make some pre-level agreements on QoS requirement for their 684 applications either based on the groups it belongs to or based on 685 the priority of the clients request (Suppose, C belongs to {Q1, 686 Q2, Q3}). Method for defining QoS classes is out of scope of the 687 present document. Once defining the groups, its priorities, QoS 688 classes, and permissions, then the conditional statements which 689 define the resource control policies can be defined as follows: 691 ST1: If the client belongs to G1 then it is allowed with 692 permissions {R, R/W, U}, priority {P1}, QoS {Q1}, and operations 693 {turn it up, read}; else if the client belongs to G2 then it is 694 allowed with permissions {R, W, R/W}, priority {P3}, QoS {Q2}, and 695 operations {turn it up, read}; else if the client belongs to G3 696 then it is allowed with permissions {D}, priority {P2}, QoS {Q3}, 697 and operations {turn it down}. 699 ST2: Allow the client with priority {P1}, QoS {Q1}, operations 700 {turn it up, turn it down, read}, and allow only with permissions 701 {R} in G1; permissions {R, R/W, D} in G2; and permissions {D} in 702 G3. 704 ST3: Allow the client with priority {P1}, QoS {Q1}, and allow with 705 permissions {R}, operations {read} in G1; allow with permissions 706 {R, R/W, D}, operations {turn it up, turn it down, read} in G2; 707 and allow with permissions {D}, operations {turn it down} in G3. 709 Above conditional statements are few examples on how to define the 710 conditional statements, the statements can be defined on any 711 manner based on the resource control policies we would like to 712 achieve. The above statements can be better explained in plain 713 semantic notation as shown in Fig 11(a)-13(a), and the 714 corresponding JSON representations for message exchange is 715 explained in Fig 11(b)-13(b). These statements can be even 716 implemented using data modeling language such as YANG or ASN 1.1 717 which is out of scope of the present document. 719 C 720 { 721 G1 |"[ 722 { |"C":{"G1":{"Allow":"R,U", 723 Allow {R,U} |"Priority":"P1","QoS":"Q1", 724 Priority {P1} |"Operations":"turnup,read"}, 725 QoS {Q1} |"G2":{"Allow":"R,W", 726 Operations {tunr it up, read}|"Priority":"P3","QoS":"Q2", 727 } |"Operations":"turn it 728 G2 |up,read"},"G3":{"Allow":"D", 729 { |"Priority":"P2","QoS":"Q3", 730 Allow {R,W} |"Operations":"turn it down" 731 Priority {P3} |}}]" 732 QoS {Q2} | 733 Operations {turn it up, read}| 734 } | 735 G3 | 736 { | 737 Allow {D} | 738 Priority {P2} | 739 QoS {Q2} | 740 Operations {turn it down} | 741 } | 742 } | 744 (a) (b) 746 Fig 11. ST1: (a) Semantic Notation (b) JSON Representation 748 C | "[ 749 { | "Priority":"P1","QoS":"Q1", 750 Priority {P1} | "Operations":"turn it up, 751 QoS {Q1} | turn it down, read", 752 Operations {turn it up,turn it | "C":{"G1":{"Allow":"R"}, 753 down, read} | "G2":{"Allow":"R,W,D"}, 754 G1 | "G3":{"Allow":"D"}} 755 { | ]" 756 Allow {R} | 757 }; | 758 G2 | 759 { | 760 Allow {R,W,D} | 761 }; | 762 G3 | 763 { | 764 Allow {D} | 765 }; | 766 } | 768 (a) (b) 769 Fig 12. ST2: (a) Semantic Notation (b) JSON Representation 771 C | "[ 772 { | "Priority":"P1","QoS": 773 Priority {P1} | "Q1","C":{"G1": {"Allow": 774 QoS {Q1} | "R","Operations":"read"}, 775 G1 | "G2":{"Allow":"R,W,D", 776 { | "Operations":"turn it up, 777 Allow {R} | turn it down, read"}, 778 Operations {read} | "G3":{"Allow":"D", 779 }; | "Operations":"turn it 780 G2 | down"}}]" 781 { | 782 Allow {R,W,D} | 783 Operations {turn it up, turn | 784 down, read} | 785 }; | 786 G3 | 787 { | 788 Allow {D} | 789 Operations {turn it down} | 790 }; | 791 } | 793 (a) (b) 794 Fig 13. ST3: (a) Semantic Notation (b) JSON Representation 796 6.4 Search for services by device 798 Any client device (as explained for scenario 2) MUST interacts 799 with the provisioning server and looks for deployed services by 800 devices. Moreover, the provisioning server can verify the complete 801 authorization, admission, and resource control of any device's 802 services. Whereas, if any other constrained devices (ex. air 803 conditioner) searches for services hosted by other constrained 804 device (as explained for scenario 1) MUST interact with the RD 805 server as shown in Fig 10. Here, initially the device queries for 806 all services that are hosted by other devices, then it searches 807 within the domain for specific service, its SRV info, and path to 808 the hosted service. Before sending a request, it MUST establish a 809 secure channel between these two nodes [draft-schmitt-ace- 810 twowayauth-for-iot]. 812 +---------------+ +----------+ 813 | Device | | RD Server| 814 | (aircondit | | | 815 | ioner) | | | 816 +-----+---------+ +-------+--+ 817 | | 818 | GET /rd-lookup/gp?d=example.com `. | 819 +---------------------------------------------------`.: 820 | .-' | 821 | .'2.05 Content | 822 ::----------------------------------------------------+ 823 | `-. | 824 | GET /rd-lookup/ep?gp=thermostat `. | 825 +----------------------------------------------------:: 826 | .' | 827 | .'2.05 Content | 828 ::----------------------------------------------------+ 829 | `. | 830 | | 831 | GET /rd-lookup/ep?et=temperature&gp=thermostat `. | 832 +----------------------------------------------------`. 833 | .' | 834 | | 835 | .'2.05 Content ;ep="Node1" | 836 ::----------------------------------------------------+ 837 | `-. | 838 | | 839 Fig. 10 Search for services by device 841 6.5 Service request and response 842 In scenario 1 (as shown in Fig 1), service request and response 843 MUST use coap based communication to access the service as shown 844 in Fig 11. Before sending a request, it MUST establish a secure 845 channel between these two nodes [draft-schmitt-ace-twowayauth-for- 846 iot]. Suppose, the constrained client device (for ex. 847 airconditioner) want to access the service hosted by another 848 constrained device (for ex. thermostat), then the client device 849 MUST send a coap based GET request to thermostat. Then, this 850 device (thermostat) SHOULD send a POST request to provision this 851 service request with the provisioning server by sending clients 852 . Based on the clients , the provisioning server 853 MUST find the client (ex. airconditioner) details such as service 854 information, group, domain, and type details. 856 +------------+ +-------------+ +-----------+ 857 |Airconditi | |Thermostat | |Provision | 858 |oner | | (IP1) | |ining Server 859 | (IP2) | | | | (IP3) | 860 +-----+------+ +------+------+ +--------+--+ 861 | | | 862 |coap://thermostat. `.| | 863 +----------------------------:: | 864 | example.com/temp .' |POST /thermostat `. | 865 | +-------------------------:: 866 | |HOST thermostat.ps. .' | 867 | | example.com | 868 | |Content-Type: application/txt 869 | |{ SRC: | 870 | | DST: | 871 | | Client: } | 872 | | | 873 | | +--------------------------+ 874 | | |Check for Admission, | 875 | | |ResourceControl of thermost 876 | | |for airconditioner | 877 | | +--------------------------+ 878 | | | 879 | | .'2.00 OK { Permit/Deny }| 880 | .'URI-Path: temp CON 200 ::------------------------+ 881 ::---------------------------+ `-. | 882 | `.("thermostat","aaaa::212.| | 883 | 7402.2.202","temp",27) | | 884 | | | 885 Fig. 11 Request/Response within Constrained Environment 887 Once the client is identified, the provisioning server MUST check 888 for authorization, admission and resource control policies of 889 hosted service (ex. thermostat). Once the service request is 890 authorized to access then the URI-Path for hosted service along 891 with the value is sent as a coap response to client device (air 892 conditioner). Here, the request is conditional i.e. based on the 893 resource control policies of a resource (such as thermostat) for a 894 client (airconditioner), the permissions are given to access the 895 resource. 897 +-------------+ +------------+ +---------+ 898 | | |Provision | | | 899 | Client | |ining Server| |Thermostat 900 | | | | | | 901 +-----+-------+ +-----+------+ +------+--+ 902 | | | 903 |http://thermostat. `. | | 904 +----------------------------:: | 905 | example.com/temp .' | | 906 | +-----------------------------+ | 907 | |Check for Admission, | | 908 | |Resource Control of thermostat | 909 | |for airconditioner | | 910 | +-----------------------------+ | 911 | | | 912 | | coap://thermostat. `. | 913 | +------------------------:: 914 | |example.com/temp .' | 915 | | | 916 | | | 917 | | .'URI-Path: temp CON 200| 918 | ::------------------------+ 919 | | `. | 920 | .' HTTP/1.1 200 OK | | 921 ::----------------------------+ | 922 | `. Temperature: 27 | | 923 | | | 924 Fig. 12 Request/Response from outside Constrained Environment 926 Service request and response in scenario 2 (as shown in Fig 2), 927 uses simple http based communication to access the service from 928 the PS. Provisioning Server then sends a coap based GET request to 929 the ultimate device that hosts service. Before sending this 930 request to the actual device for service, PS authorizes the 931 service request. Once, the service request is authorized to 932 access, then the URI-path for hosted service along with the value 933 is sent as HTTP response to client device. PS can implement a 934 reverse proxy case for HTTP-CoAP protocol translation defined in 936 [draft-ietf-core-http-mapping]. 938 ------------------HTTP begin ------------------------------------- 939 HTTP POST 940 Request: 941 POST /thermostat /HTTP/1.1 942 HOST thermostat.example.com 943 Content-Type: application/x-www-form-urlencoded 944 Content-Length: length 945 licenseID=string & content=string & paramsXML=string 947 Response: 948 HTTP/1.1 200 OK 949 Content-Type: text/xml; charset=utf-8 950 Content-Length: length 951 952 953 string 954 956 ------------------HTTP end ------------------------------------- 958 ------------------ REST via HTTP begin -------------------------- 959 REST via HTTP POST 960 Request: 961 POST /thermostat /HTTP/1.1 962 HOST thermostat.example.com 963 Content-Type: application/x-www-form-urlencoded 964 Content-Length: length 966 licenseID=string & content=string & paramsXML=string 968 Response: 969 HTTP/1.1 200 OK 970 Content-Type: text/xml; charset=utf-8 971 Content-Length: length 973 string 975 ------------------REST via HTTP end ----------------------------- 977 ------------------SOAP begin ------------------------------------ 979 SOAP 1.2 980 Request: 981 POST /Thermostat /HTTP/1.1 982 HOST: www.example.org 983 Content-Type: application/soap+xml; charset=utf-8 984 Content-Length: length 986 987 988 Xmlns:soap=http://www.w3.org/2001/12/soap-envelop 989 Soap:encodingStyle=http://www.w3.org/2001/12/soapencoding> 990 991 992 1 993 994 995 997 Response: 998 HTTP/1.1 200 OK 999 Content-Type: application/soap+xml; charset=utf-8 1000 Content-Length: length 1002 1003 1004 Xmlns:soap=http://www.w3.org/2001/12/soap-envelop 1005 Soap:encodingStyle=http://www.w3.org/2001/12/soapencoding> 1006 1007 1008 27.8 1009 1010 1011 1013 ------------------SOAP end ---------------------------------- 1015 7 Security Considerations 1017 Security level for message authentication is out of scope of the 1018 present document. However, the following security consideration 1019 needs to be considered for the present proposed method. Services 1020 that run over UDP are unprotected and vulnerable to unknowingly 1021 become part of a DDoS attack as UDP does not require return 1022 routability check. Therefore, an attacker can easily spoof the 1023 source IP of the target entity and send requests to such a service 1024 which would then respond to the target entity. The TLS/DTLS based 1025 security solution can be considered for secure message 1026 communication. 1028 8 IANA Considerations 1029 TBD 1031 9 References 1033 9.1 Normative References 1035 9.2 Informative References 1037 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1038 Requirement Levels", BCP 14, RFC 2119, March 1997. 1040 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1041 Constrained-Node Networks", RFC 7228, May 2014. 1043 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1044 "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 1045 4944, September 2007. 1047 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1048 Application Protocol (CoAP)", RFC 7252, June 2014. 1050 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1051 Format", RFC 6690, August 2012. 1053 [draft-ietf-core-resource-directory] Shelby, Z., and Bormann, C., 1054 "CoRE Resource Directory", draft-ietf-core-resource-directory-02 1055 (work in progress), November 2014. 1057 [draft-gerdes-ace-actors] Gerdes, S., "Actors in the ACE 1058 Architecture", draft-gerdes-ace-actors-03 (work in progress), 1059 March 2015. 1061 [draft-gerdes-ace-dcaf-authorize] Gerdes, S., Bergmann, O., Bormann, 1062 C., "Delegated CoAP Authentication and Authorization Framework 1063 (DCAF)", draft-gerdes-ace-dcaf-authorize-02, March 2015. 1065 [draft-bormann-core-ace-aif] Bormann, C., "An Authorization 1066 Information Format (AIF) for ACE", draft-bormann-core-ace-aif-oo, 1067 January 2014. 1069 [draft-schmitt-ace-twowayauth-for-iot] Schmitt, C., Stiller, B., 1070 "Two-way Authentication for IoT", draft-schmitt-ace- twowayauth- 1071 for-iot-01, December 2014. 1073 [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1074 Security", RFC 6347, January 2012. 1076 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.2", RFC 1077 5246, August 2008. 1079 [draft-ietf-core-http-mapping] Castellani, A., Loreto, S., Rahman, 1080 A., Fossati, T., and Dijk, E., "Guidelines for HTTP-CoAP Mapping 1081 Implementations", draft-ietf-core-http-mapping-05, (work in 1082 progress), Oct 2015. 1084 10 Acknowledgements 1086 Special thanks to Amit Kumar S,Zhengfei, Fubaicheng, 1087 Yangjun,Vijayachandran Mariappan, Shashidhar C Shekar, 1088 Jayaraghavendran K, Ajay Sankar, Puneet Balmukund Sharma, and Rabi 1089 Narayan Sahoo for extensive comments and contributions that improved 1090 the text. 1092 Thanks to Hedanping (Ana), Behcet Sarikaya, and Carsten Bormann for 1093 helpful comments and discussions that have shaped the document. 1095 Authors' Addresses 1097 Vasu K 1098 Huawei Technologies 1099 Bangalore 1100 India 1102 EMail: vasu.kantubukta@huawei.com 1104 Rahul A Jadhav 1105 Huawei Technologies 1106 Bangalore 1107 India 1109 EMail: rahul.jadhav@huawei.com 1111 yangneng 1112 Huawei Technologies 1113 Shenzhen 1114 China 1116 EMail: yangneng@huawei.com