Internet DRAFT - draft-vasu-ace-core-access-privilege-provisioning

draft-vasu-ace-core-access-privilege-provisioning



 



Internet Engineering Task Force                                   Vasu K
INTERNET-DRAFT                                                 Rahul A J
Intended Status: Standard Track                                 Yangneng
Expires: Oct 15, 2016                                             Huawei
                                                          April 15, 2016


         Access Privilege Provisioning for Constrained Devices 
          draft-vasu-ace-core-access-privilege-provisioning-00


Abstract

   As more constrained devices are integrating with current Internet,
   the ubiquitous computing in scenarios like smart home is very
   important. In smart home, the constrained devices (ex. thermostat)
   need to be provisioned in such a way that it can inter-operate with
   any kind of devices like other constrained devices (ex. Air
   conditioner) or client devices (ex. smart phone). This document
   provides a method to support access privilege provisioning based on
   pre-configured admission and resource control policies, where this
   method explains device's service access in two different use cases:
   first provisioning the service when a constrained device accessing
   the service provided by other constrained device, second, accessing
   the service provided by constrained device from the client device
   (non constrained device).

Status of this Memo This Internet-Draft is submitted to IETF in full
   conformance with the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on Oct 15, 2016.

 


Vasu K                    Expires Oct 15, 2016                  [Page 1]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


Copyright and License Notice

   Copyright (c) 2016 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.




Table of Contents

   1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4  System Architecture . . . . . . . . . . . . . . . . . . . . . .  6
   5 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . 10
   6 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1 Discover Provisioning Server . . . . . . . . . . . . . . . . 11
     6.2 Register Service . . . . . . . . . . . . . . . . . . . . . . 12
     6.3 Verify pre-registered service  . . . . . . . . . . . . . . . 13
     6.4 Define policies on resource control  . . . . . . . . . . . . 14
       6.4.1 Resource Control . . . . . . . . . . . . . . . . . . . . 16
     6.5 Search for services by device  . . . . . . . . . . . . . . . 19
     6.6 Service request and response . . . . . . . . . . . . . . . . 20
   7 Alternative Solution . . . . . . . . . . . . . . . . . . . . . . 24
     7.1 System Architecture  . . . . . . . . . . . . . . . . . . . . 24
     7.2 Service Request  . . . . . . . . . . . . . . . . . . . . . . 25
   8  Security Considerations . . . . . . . . . . . . . . . . . . . . 27
   9  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 28
   10  References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 28
     10.2  Informative References . . . . . . . . . . . . . . . . . . 28
   11  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30





 


Vasu K                    Expires Oct 15, 2016                  [Page 2]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


1 Introduction

   The work on Constrained Restful Environment (CoRE) aimed to realize
   the restful architecture for constrained devices [RFC7228] in
   constrained networks [RFC4944]. The CORE work group has recently
   standardized constrained application protocol (CoAP) [RFC7252] for
   interacting with constrained resources where general HTTP is not  
   memory/energy efficient. The use of web linking for resources
   description and discovery hosted by constrained web servers is
   specified by CORE [RFC6690]. Even though, CoAP allows the direct
   resource access for constrained devices, it is not advisable for
   direct access of resources in networks where multicast procedures are
   infeasible due to heavy network load, and the networks where sleepy
   nodes exist. So, the CoRE working group comes up with a solution
   called resource directory (RD) [draft-ietf-core-resource-directory]
   to host the devices service information, and allow other devices to
   perform lookup procedures through .well-known/core path to resources.
   Once the services are advertised by any device, those services need
   to be verified using commissioner. CORE RD provides a standard
   procedure to interact with commissioner, where commissioner acts like
   a client device to look up and verify the advertised services. Once
   the commissioner verifies the pre-registered services, commissioner
   can put some policy rules on services hosted by devices for resource
   control. These rules defined on (1) how to access the services either
   with other constrained devices or client devices, and (2) on
   operational instructions.   

   Architecture is defined to authenticate and authorize client requests
   for a resource on a server using logical entities such as client(C),
   client authorization manager (CAM), server(S), and server
   authorization manager (SAM) [draft-gerdes-ace-actors]. The main goal
   of delegated CoAP authentication and authorization framework (DCAF)
   is the setup of a datagram transport layer security channel between
   two nodes to securely transmit authorization tickets [draft-gerdes-
   core-dcaf-authorize]. The CAM sends an access request message on
   behalf of client by embedding requested permissions in client
   authorization information (CAI) field of access request message to
   SAM. A ticket grant message is sent from SAM by embedding the
   permissions given from the server on a specific resource in server
   authorization information (SAI) field of ticket grant message to the
   client. These SAI, CAI use authorization information format (AIF)
   that describes the permissions requested from access request in a
   ticket request, where the underlying access control model will be
   that of an access matrix, which gives a set of permissions for each
   possible combination of a subject and an object [draft-bormann-core-
   ace-aif]. This simple information model also doesn't allow
   conditional access (e.g.,"resource /s/tempC is accessible only if
   client belongs to group1 and does not belong to group2"). 
 


Vasu K                    Expires Oct 15, 2016                  [Page 3]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


   Admission control is addressed with the draft (draft-seitz-ace-oauth-
   authz) provides a mechanism for pre-configuring secure/authorization
   policies with token mechanism to access the resource. It is not
   possible to manage the rest resources by using only tokens that
   authorize the clients to access the resource. Because, it also needs
   to handle resource control interms of various other parameters such
   as priority of request, QoS, Operations that can be performed on
   resource by various clients. The draft (draft-seitz-ace-oauth-authz)
   talks about how to provide admission control (conditional
   authorization) for resource access from client device, but it does
   not consider constrained device access from another constrained
   device. So, we integrated our solution with RD, and commissioning
   procedures along with admission control (AC), and resource control
   (RC) of resources. Moreover, we provide the mechanism for resource
   access from another constrained device.

   For example, consider a user leaves the home in the morning in hot
   summer and leaves the office in the evening to reach to home. But,
   before he reaches his room he wants to make his room cool enough. So
   he has to switch on the air-conditioner from his mobile one hour
   before he leaves the office. So, before adjusting his air-conditioner
   to make the room cool enough, he might have to know the current room
   temperature. Thus he access the service provided by the thermostat to
   read the room temperature and adjust the air-conditioner. However,
   there is a problem here on how to access these services which are
   provided by user's home devices because there may be issues at device
   such as 1) what is the authenticity level 2) the device might be
   overloaded from other resource access 3) the device is protected at
   that time to keep long lifetime 4) Allow only specified users to
   control it and 5) how to set quality control on resource access. 

   The access privilege provisioning presented in this document provides
   method to configure the policies for admission as well as resource
   control in constrained environment (including both constrained and
   non-constrained devices) that includes complete system architecture,
   methods for defining policies, and with commissioning procedures.
   Here, the service provisioning includes authentication,
   authorization, admission and resource control. 

2 Motivation

   CORE RD solution provides various automated operations such as
   service registrations, service update, service removal, and service
   lookups initiated by endpoints and clients. However, managing this
   centralized directory server by allowing authorized users to perform
   these tasks, setting some service level agreements on clients to
   access these services, and providing limited or scope oriented
   lookups by other endpoints or clients require efficient service
 


Vasu K                    Expires Oct 15, 2016                  [Page 4]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


   provisioning mechanism. The access privilege provisioning method
   presented in this document deals on how a registered service from
   devices can be accessed by various clients or other devices.
   Moreover, it also provides a method for handling resource/service
   access control mechanism for efficient service provisioning from
   outside the constrained home environment.

3 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

      o "CORE", CORE is a Constrained RESTful Environment providing a
      framework for resource-oriented application intended to run on
      constrained networks [RFC7228]. 

      o "COAP" The Constrained Application Protocol (CoAP) is a
      specialized web transfer protocol for use with constrained nodes
      and networks [RFC7252].

      o "RD" The Resource Directory (RD) is a directory based server to
      host the descriptions of resources and allowing the lookups to be
      performed for those resources by various client devices.

      o "Commissioner" Commissioning agent is tool/device that verifies
      the devices operation, integrity check with the network.

      o "Constrained Device" These are embedded computing devices that
      are expected to be as resource constrained in terms of RAM/ROM
      size, and to be deployed with the constrained environment such as
      6LoWPAN Networks. This is also known as Thing. 

      o "Client" A client device is like resource constrained client
      such as other constrained device (ex. Air conditioner) or rich
      client devices such as Mobile/Laptop/Tablet etc, which access the
      services hosted by constrained devices (ex. thermostat).

      o "Provisioning Server" this server is a process of verifying
      service requester, providing access control/admission control and
      resource control on resources to be accessed and inter-operating
      with various devices without bothering about kind of network
      protocols used. It provides a method to access a resource either
      inside or outside the constrained environment.

      o "Device Profile" A device profile comprises a set of attributes
      that are associated with a particular device. These include
      services, features, names, descriptions etc.
 


Vasu K                    Expires Oct 15, 2016                  [Page 5]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


4  System Architecture


                                  +--------+    IF-e    +--------+
                                  |Thing   |............|Thing   |
                                  |(Client)`.           |(Server)|
                                  +---X----+ `. IF-d   .'----+---+
                                      X        `.    .'      |
                                      X          `-.'        | IF-a
                                IF-h  X          .' `.       |
                                      X        .'     `.     |
             +----------+         +---X----+ .'IF-f     `.---+----+
             |          |         |        .'           |   RD    |
             | Client   XXXXXXXXXXX  PS    |            |         |
             |          | IF-g    |        |            +----+----+
             +----------+         +------+-+                /
                                          \                /
                                           \ IF-c         / IF-b
         XXXXXXX  Client Access Resource    \            /
                                             ----------+-+
         -------- Service Registration &     |            |
                  Configuring Policies       |    CA      |
         ........ Constrained device access  |            |
                  resource                   |            |
                                             +------------+
         PS-Provisionig Server
         RD-Resource Directory
         CA-Commissioning Agent

                           Fig 1. System Architecture


      The system architecture is as shown in Fig 1. The thing (device),
      always registers its service with RD server. CA verifies
      registered service with RD server and configures policies at
      provisioning server for resource access by various other devices
      or clients. The following interfaces are used in the system
      architecture

      IF-a: register service (coap)
      IF-b: verify service (coap)
      IF-c: configure policies (http)
      IF-d: service search (coap)
      IF-e: obtain resource for constrained devices (coap)
      IF-f: check for admission/resource control policies for service
      (coap)
      IF-g: Service request for non-constrained device (http)
      IF-h: Obtain resource for non-constrained devices (coap)
 


Vasu K                    Expires Oct 15, 2016                  [Page 6]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      The system architecture is better explained with two different
      scenarios: (1) Constrained device access the service advertised by
      other constrained device is as shown in Fig 2. Here, one
      constrained device such as air-conditioner can access the service
      such as current room temperature advertised by other constrained
      device (ex. thermostat). This advertised service is to be
      commissioned by commissioner, and then it should be set with some
      admission and resource control policies by provisioning server.
      And, finally the service is allowed to advertise its service
      access from other constrained devices. Any device that is
      interested in that advertised service, need to do service lookup
      from RD Server. Once obtaining the path to the advertised service,
      the constrained client device can request a service to the device
      which hosts the service. Before sending the request, it MUST
      establish a secure channel between these two nodes [draft-schmitt-
      ace-twowayauth-for-iot]. Once the incoming request comes from the
      constrained client device, the device which hosts the service MUST
      authorize and provision for conditional access of its service from
      the provisioning server. The notification regarding the registered
      services to the commissioning agent can be sent from the RD
      server, which can be implementation specific and left for the user
      to choose any standard procedures and is out of scope of present
      document. Detailed operational procedure will be explained in the
      later sections of this document.

      2) Client device access the service advertised by constrained
      device is as shown in Fig 3. For example, the client device such
      as smart phone can access the service (ex. room temperature)
      advertised by other constrained device (ex. thermostat). The
      client can access the service within a home environment or outside
      the home environment. So, in this scenario, the provisioning
      server maintains the service as a web service.  

      This advertised service is to be commissioned by commissioner,
      then to be set with some admission and resource control policies
      by provisioning server. And, finally the service is allowed to
      advertise its access from the client devices. Any client that
      wishes to access this web service looks for corresponding
      operations provided from the provisioning server. 









 


Vasu K                    Expires Oct 15, 2016                  [Page 7]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       +------+  +-------+   +-----+   +--------+  +----------+
       |Device1  |Device2|   | RD  |   |Provis  |  |Commision
       |(Air     |(Thermo|   |     |   |ioning  |  |ing       |
       |Condi |  |  stat)|   |Serv     |Sever   |  |Agent     |
       |tioner)  |       |   |er   |   |        |  |          |
       +--|---+  +----|--+   +--|--+   +----|---+  +-----|----+
          |           |         |           |            |
          |           |         |           |            |
          |           |Register |           |            |
          |           ----------//          |            |
          |           | Service/|  Verify Preregistered\ |/
          |           |         ------------------------//
          |           |         |    Service|         // |
          |           |         |           |        /   |
          |           |         |           |            |
          |           |         |           |            |
          |           |         |           |            |
          |           |         |           |//Define    |
          |           |         |          /-------------
          |           |         |         / \ Policies   |
          |Search a Service  \  |           |            |
          ---------------------//           |            |
          |           |       //|           |            |
          |           |      /  |           |            |
          |           |         |           |            |
          |           |         |           |            |
          |Request    |         |           |            |
          -----------/          |           |            |
          |Service   /|         |           |            |
          |         / |         |           |            |
          |           |Check for authorization           |
          |           |admission, Resource  |            |
          |           ---------------------//            |
          |           | Control Policies  //|            |
          |           |         |        /  |            |
          |           |         |           |            |
          |           |         |           |            |
          |           | // Service Grant/Deny            |
          |           /---------------------             |
          |          /|\        |           |            |
          |  /        |         |           |            |
         \//Service  |          |           |            |
          /\----------          |           |            |
          |    Grant/Deny       |           |            |
          |           |         |           |            |

      Fig 2.Constrained device accessing service from constrained device

 


Vasu K                    Expires Oct 15, 2016                  [Page 8]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       +--------+  +-------+  +-------+  +---------+ +---------+
       |Client  |  |Device2|  |RD     |  |Provision| |Commissi |
       |(Smart  |  |(Thermo|  |Server |  |ing Server |oning    |
       | Phone) |  | stat) |  |       |  |         | |Agent    |
       |        |  |       |  |       |  |         | |         |
       |        |  |       |  |       |  |         | |         |
       +---|----+  +---|---+  +---|---+  +----|----+ +-----|---+
           |           |          |           |            |
           |           |          |           |            |
           |           |Register  |           |            |
           |           -----------/           |            |
           |           |Service   /           |            |
           |           |         /|           |            |
           |           |          |  /        |            |
           |           |          |//Verify Preregistered  |
           |           |          --------------------------
           |           |          |\    Service            |
           |           |          |           |            |
           |           |          |           |            |
           |           |          |           |  /         |
           |           |          |           |//Define    |
           |           |          |           -------------
           |           |          |           |\ Policies  |
           |           |          |           |            |
           | Request for Service  |        \               |
           ----------------------------------//            |
           |           |          |         //|            |
           |           |          |        /  |            |
           |           |          |           |            |
           |           |  /       |           |            |
           |           |// Request| for Service            |
           |           -----------------------             |
           |           |          |           |            |
           |           |          |           |            |
           |           |          |           |            |
           |           | Service Grant/Deny\  |            |
           |           ----------------------/             |
           |           |          |         //|            |
           |           |          |        /  |            |
           |           |          |           |            |
           |           |          |           |            |
           |  //       |          |           |            |
           |//   Service Grant/Deny           |            |
           \----------------------------------            |
           | \         |          |           |            |
           |           |          |           |            |

           Fig 3. Client accessing service from Constrained device
 


Vasu K                    Expires Oct 15, 2016                  [Page 9]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


5 Network Topology

             -------                      --------
           //       \                  //        \
          /                          //            \
         /                          /                
        /                          /                  
        | +--------+    |           |        +--------+|
       |  |RD Server---| |         | +-----+ |Thermostat|
       |  +--------+   | | LAN     | |Edge | +--------+ |
       |               |------|-------     |            |
       |  +----------+ | |    |    | |Router 6LoWPAN    |
        | |Provision --||     |     |+-----+           |
         |Server    |  /     |          +--------+   /
         +----------+ /      |          |Aircondioner
                     /       |       \  +--------+//
           \       //        |         \        //
             -------          |           --------
                              |
                              |
                             -|-----
                          //- |     -\
                        //  +-|----+   \
                       /    |Edge  |     
                      /     |Router|      
                      |     +------+      |
                     |                     |
                     |    WiFi             |
                     |   +-------+ +-----+ |
                     |   |Smart  | |Commisioning
                      |  |Phone  | | Agent|
                        +-------+ +-----+/
                                        /
                        \             //
                          \-       -//
                             -------

                    Fig 4. Network Topology

      The constrained devices such as Thermostat, Airconditioner may use
      small memory constrained sensors/actuators for simple services
      such as cooling/heating the room or just to measure the current
      room temperature. These memory constrained embedded devices may
      implement the 6LoWPAN stack such as uIP (provided by Contiki), and
      provide access for communication to other external queries from
      client devices such as smart phone which typically implements rich
      stack TCP/IP. Even though RD server or Provisioning server are
      shown as separate servers in the LAN as given in Fig 4, these can
 


Vasu K                    Expires Oct 15, 2016                 [Page 10]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      be hosted on a single server running two different processes.
      Moreover, the commissioner implements a standard procedure to
      interact with devices as a separate agent process which is out of
      scope of the present document and has been left to user's choice
      while satisfying the mentioned operations in the current draft. On
      the other hand, these specific operations can be implemented
      separately as a third party and to be used at the commissioning
      agent. The lower level communication technology can be implemented
      either through Bluetooth (BT) or near field communication (NFC) to
      verify the devices unique ID (for ex. using MAC). Even though, the
      implementation procedure for commissioner is out of scope for the
      present document, it is shown as sample interaction with RD
      server/provisioning server as part of commissioning procedure in
      subsequent sections. Even though the present document discusses
      about 6LoWPAN based sensor network, it can be easily moved to any
      other technology such as Zigbee/BLE/Wireless HART without any
      changes in the architecture or design, because the present
      document abstracted the communication networks with their edge
      routers. The communication and routing mechanisms or procedure
      between edge router and sensor devices/client devices are out of
      scope of the present document.

6 Operations

6.1 Discover Provisioning Server

      Suppose a client device request for a resource which is hosted on
      device that 1) might be unreachable 2) far distant from the
      requesting client/device 3) cannot hold more requests 4) might not
      intend to provide any resource and 5) want to allow limited
      operations; querying that resource is waste of communication
      resource. Because, the resource directory server won't be aware
      until the device/thing do explicit delete operation. The client or
      device which accesses the resource should be provisioned
      dynamically for admission and resource control. To query for
      resource, the client or device should only query for resource
      type, kind of operation it want, and optionally an endpoint. With
      this information, the provisioning server should be able to decide
      which resource to grant, where the PS might use the conditional
      statements made for each resource. When the PS is in network,
      client or device can make the following well-known queries for the
      provisioning server:

                   rt=core.ps ---- Provisioning server
                     =core.ps.search ---- Resource search

      Here, core.ps returns resource type as provisioning server, and
      "core.ps.search" is used to search for any specific resource
 


Vasu K                    Expires Oct 15, 2016                 [Page 11]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      queries, the following query options are allowed under
      provisioning server:

                   op --- operation
                   rt --- resource type
                   ep --- endpoint

      The following example explains about how a well-know query for
      provisioning server should be done:

             REQ: GET /.well-known/core rt=core.ps
             RES: </ps> ; "rt=core.ps"

      And, the following example explains about how a query options can
      be used to search for resource on provisioning server.

      REQ: GET coap://ps.example.com/core.ps.search/ep?op=read&rt=temp
      RES: <coap://[aaaa::212.7402.2.202]:61616/temp>; ep=node1;
      rt=temp;

6.2 Register Service

         +---------+                                         +---------+
         |         |                                         |         |
         | Device  |                                         |RD Server|
         |         |                                         |         |
         +----+----+                                         +-----+---+
              |                                                    |
              |                                                    |
              |                                               `.   |
              | POST /rd?ep=node1&d=example.com&et=temperature-no`.|
              +--------------------------------------------------,'.
              | gp=thermostat&con=DeviceID(100)                ,'  |
              |                                              ,'    |
              |   ,'                                               |
              | ,'  2.01 Created Location: /rd/7521                |
              `.----------------------------------------------------
              | `-.                                                |
              |    `.                                              |
              |                                                    |

                   Fig. 5 Registering a Service

      The constrained device which hosts the service MUST register its
      service with the RD server using its unique identifier (for ex.
      MAC id, UDDI registry etc.) and IP address as shown in Fig 5. The
      device MUST send a POST request for registering its service.
      Before sending a request, it MUST establish a secure channel
 


Vasu K                    Expires Oct 15, 2016                 [Page 12]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      between these two nodes [draft-schmitt-ace-twowayauth-for-iot].
      Once the service has been registered with the RD server, the RD
      server may notify the registered information of a device (for
      ex.its unique identifier and device name) to a commissioning
      agent.

6.3 Verify pre-registered service


       +---------------+                                  +----------+
       |Commissioning  |                                  | RD Server|
       |Agent          |                                  |          |
       +------+--------+                                  +--------+-+
              |                                                    |
              |                                                    |
              |     GET /rd-lookup/d                           `.  |
              +--------------------------------------------------:'.
              |                                                .'  |
              |                                                    |
              | .'2.05 Content </rd>;d=example.com,</rd>;d=example.com
              ::---------------------------------------------------+
              | `-.                                                |
              |   GET /rd-lookup/gp?ep=node1&d=example.com      `. |
              +---------------------------------------------------/.
              |                                                 .' |
              |                                                    |
              | .'2.05 Content <coap://ip:port>;gp=thermostat;ep=node1
              ::---------------------------------------------------+
              | `-.                                                |
              |                                               `.   |
              | GET /rd-lookup/res?rt=temp&gp=thermostat&d=example.com
              +--------------------------------------------------:'.
              |                                                .'  |
              |                                                    |
              | .'2.05 Content <coap://host:port>;rt=temp;gp=thermostat
              ::---------------------------------------------------+
              | `-.                              d=example.com     |
      +---------------------------+                                |
      |Authentication of Service  |                                |
      |Info and DeviceID          |                                |
      +---------------------------+ POST Verified User; DeviceID`. |
              +---------------------------------------------------::
              | .'                                             .-' |
              .`.__________________________________________________|
              |  `.    2.00 OK                                     |

            Fig. 6 Verify pre registered service

 


Vasu K                    Expires Oct 15, 2016                 [Page 13]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


               SRV {
                     Name: Node1
                     Group: Thermostat
                     Domain: myhome.com
                     Type: Temperature node
                     Device ID: 1001
                     Device IP: <host:port>
                   }
                     Fig 7. Example Service Information


      The commissioning agent MUST verify any pre registered service
      with the RD server as shown in Fig 6. The commissioning agent
      sends a GET request for domain lookup. Before sending the request,
      it MUST establish a secure channel between these two nodes
      [DTLS][TLS]. Once obtaining the specific domain, it MUST look for
      the group to which the service belongs. Once obtaining the
      specific domain and group, it MUST send a service look up with the
      RD server for the registered service. Once obtaining the service
      information about a specific device, the commissioning agent MUST
      verify the registered service. This service information is later
      used to create service registry in the provisioning server as
      explained in the following section. The example service
      information (denoted as SRV) looks like as shown in Fig 7.

6.4 Define policies on resource control

      Once the hosted service has been verified by commissioning agent
      (CA), the CA MUST create a service registry with the provisioning
      server as explained in Fig 8. The provisioning server SHOULD send
      a service ID as a response back to the commissioning agent after
      creating the service entry. 

      This service ID can be later used by the commissioning agent to
      permanently DELETE the service entry ( if required). The
      commissioning agent MUST create some admission control policies
      such as read (R), write (W), read/write (R/W), delete (D), number
      of simultaneous connection on resource etc.  on the registered
      service. Once the admission control policies has been set on a
      specific device, the resource control policies such as conditional
      access of a service, quality of service agreements (based on the
      priority levels set for clients) can be set on that registered
      service. These conditional access on service can be implemented
      with simple conditional statements as explained in section 6.3.1 
      (for ex. "client (c) can access service with only read (R), write
      (W) permissions if it only belongs to group (g)").


 


Vasu K                    Expires Oct 15, 2016                 [Page 14]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       +----------------+                        +---------------+
       |Commissioning   |                        |Provisioning   |
       | Agent          |                        | Server        |
       +------+---------+                        +--------+------+
              |  POST /thermostat /HTTP/1.1            `. |
              +------------------------------------------/.
              |  HOST thermostat.ps.example.com        .' |
              |  Content-Type: application/text           |
              |  SRV { Name: Node1                        |
              |        Group: Thermostat                  |
              |        Domain: myhome.com                 |
              |        Type: Temperature-node             |
              |        DeviceID: 1001                     |
              |        DeviceIP: <host:port> }            |
              |                                           |
              | .'     HTTP/1.1 200 OK                    |
              ::------------------------------------------'
              | `.     Content-Type: application/text     |
              |        { sID (service ID) }               |
              |                                           |
              |  POST /thermostat /HTTP/1.1            `. |
              +------------------------------------------::
              |  HOST thermostat.ps.example.com        .' |
              |  Content-Type: application/text           |
              |  AC { ServiceID: 1234                     |
              |       Auth: Basic Auth Support            |
              |       Count: 10                           |
              |       Admission Control: R,W,R/W,D }      |
              |                                           |
              | .'    HTTP/1.1 200 OK                     |
              ::------------------------------------------+
              | `.    Content-Type: application/text      |
              |                                           |
              |  POST /thermostat /HTTP/1.1            `. |
              +------------------------------------------::
              |  HOST thermostat.ps.example.com        .' |
              |  Content-Type: application/text           |
              |  RC { If C is from G1 allow {R,W};        |
              |       If C is from G2&!G3 allow {R};      |
              |       If C is from d1&g1 allow {R,W,D};   |
              |        : }                                |
              | .'    HTTP/1.1 200 OK                     |
              ::------------------------------------------+
              | `.    Content-Type: application/text      |
              |                                           |
            Fig. 8 Defining Policies on Resource and Access Control
      The implementation or information format details of these
      conditional statements is out of scope of the present document
 


Vasu K                    Expires Oct 15, 2016                 [Page 15]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      (TBD). The example admission control and resource control policies
      are as shown in Fig 9, and Fig 10 respectively.

               AC {
                     Service ID: 12345
                     Auth: Basic Auth Support
                     Count: 10
                     Admission Control: R, W, R/W, D
                       :
                       :
                  }

                     Fig 9. Example Admission Control Policies 

               RC {
                     If c is from g1 allow {R,W}
                     If C is from g2 & !g3 {R}
                     If C is from d1 & g1 allow {R, W, D}
                       :
                       :
                  }

                     Fig 10. Example Resource Control Policies 

6.4.1 Resource Control 

      Resource control policies for constrained devices are expressed in
      terms of conditional expressions as explained in Fig. 10. Consider
      a scenario where we define the client (C) (who accesses the
      resource) in terms of groups/levels. For example in a typical home
      building, we assign each floor as a group. Suppose for a three
      floor building, the clients such as mobile phone/air conditioner
      can belong to any of the floor within a building. And we allow
      various permissions for the clients according to the group it
      belongs to, as specified in Fig 11.

                            ---------------------------
                            |       |     |   |   |   |
                            |Client |  R  | W | U | D |
                            |-------------|---|---|---|
                            |G1     |  *  | - | * | - |
                            |       |     |   |   |   |
                            |G2     |  *  | * | - | - |
                            |       |     |   |   |   |
                            |G3     |  -  | - | - | * |
                            |--------------------------
                           Fig 11. Example Permissions on Methods

 


Vasu K                    Expires Oct 15, 2016                 [Page 16]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      Suppose, we assigned the priorities for different groups as C
      belongs to {G1, G2, G3} => {P1, P3, P2}. Moreover, if we would
      like to assign different QoS classes for clients, depending on the
      applications they use then it is required to control QoS policies
      in resource control. QoS is defined in terms of various parameters
      such as {availability, reliability, serviceability, data accuracy,
      aggregation delay, coverage, fault tolerance, network lifetime} in
      wireless sensor networks. It is assumed that based on these
      parameters, QoS is defined in terms of various classes such as
      {Q1, Q2, Q3}, then it is required that some of the clients can
      make some pre-level agreements on QoS requirement for their
      applications either based on the groups it belongs to or based on
      the priority of the clients request (Suppose, C belongs to {Q1,
      Q2, Q3}). Method for defining QoS classes is out of scope of the
      present document. Once defining the groups, its priorities, QoS
      classes, and permissions, then the conditional statements which
      define the resource control policies can be defined as follows: 

      ST1: If the client belongs to G1 then it is allowed with
      permissions {R, R/W, U}, priority {P1}, QoS {Q1}, and operations
      {turn it up, read}; else if the client belongs to G2 then it is
      allowed with permissions {R, W, R/W}, priority {P3}, QoS {Q2}, and
      operations {turn it up, read}; else if the client belongs to G3
      then it is allowed with permissions {D}, priority {P2}, QoS {Q3},
      and operations {turn it down}.

      ST2: Allow the client with priority {P1}, QoS {Q1}, operations
      {turn it up, turn it down, read}, and allow only with permissions
      {R} in G1; permissions {R, R/W, D} in G2; and permissions {D} in
      G3.

      ST3: Allow the client with priority {P1}, QoS {Q1}, and allow with
      permissions {R}, operations {read} in G1; allow with permissions
      {R, R/W, D}, operations {turn it up, turn it down, read} in G2;
      and allow with permissions {D}, operations {turn it down} in G3.

      Above conditional statements are few examples on how to define the
      conditional statements, the statements can be defined on any
      manner based on the resource control policies we would like to
      achieve. The above statements can be better explained in plain
      semantic notation as shown in Fig 12(a)-14(a), and the
      corresponding JSON representations for message exchange is
      explained in Fig 12(b)-14(b). These statements can be even
      implemented using data modeling language such as YANG or ASN 1.1
      which is out of scope of the present document.



 


Vasu K                    Expires Oct 15, 2016                 [Page 17]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       C
       {
          G1                               |"[
          {                                |"C":{"G1":{"Allow":"R,U",
              Allow {R,U}                  |"Priority":"P1","QoS":"Q1",
              Priority {P1}                |"Operations":"turnup,read"},
              QoS {Q1}                     |"G2":{"Allow":"R,W",
              Operations {tunr it up, read}|"Priority":"P3","QoS":"Q2",
          }                                |"Operations":"turn it 
          G2                               |up,read"},"G3":{"Allow":"D",
          {                                |"Priority":"P2","QoS":"Q3",
              Allow {R,W}                  |"Operations":"turn it down"
              Priority {P3}                |}}]"
              QoS {Q2}                     |
              Operations {turn it up, read}|
          }                                |
          G3                               |
          {                                |
              Allow {D}                    |
              Priority {P2}                |
              QoS {Q2}                     |
              Operations {turn it down}    |
          }                                |
       }                                   |
                      (a)                                 (b)
             Fig 12. ST1: (a) Semantic Notation  (b) JSON Representation
       C                                 | "[
       {                                 | "Priority":"P1","QoS":"Q1",
          Priority {P1}                  | "Operations":"turn it up, 
          QoS {Q1}                       | turn it down, read",
          Operations {turn it up,turn it | "C":{"G1":{"Allow":"R"},
                      down, read}        |      "G2":{"Allow":"R,W,D"},
          G1                             |      "G3":{"Allow":"D"}}
          {                              | ]"
              Allow {R}                  |
          };                             |
          G2                             |
          {                              |
              Allow {R,W,D}              |
          };                             |
          G3                             |
          {                 
                                         |
              Allow {D}                  |
          };                             |
       }                                 |
                    (a)                                  (b)
             Fig 13. ST2: (a) Semantic Notation  (b) JSON Representation
 


Vasu K                    Expires Oct 15, 2016                 [Page 18]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       C                                    | "[
       {                                    | "Priority":"P1","QoS":
           Priority {P1}                    | "Q1","C":{"G1": {"Allow":
           QoS {Q1}                         | "R","Operations":"read"},
           G1                               | "G2":{"Allow":"R,W,D",
           {                                | "Operations":"turn it up, 
               Allow {R}                    | turn it down, read"},
               Operations {read}            | "G3":{"Allow":"D",
           };                               | "Operations":"turn it 
           G2                               | down"}}]"
           {                                |
               Allow {R,W,D}                |
               Operations {turn it up, turn |
                           down, read}      |
           };                               |
           G3                               |
           {                                |
               Allow {D}                    |
               Operations {turn it down}    |
           };                               |
       }                                    |  

                    (a)                                   (b)
             Fig 14. ST3: (a) Semantic Notation (b) JSON Representation

6.5 Search for services by device 

      Any client device (as explained for scenario 2) MUST interacts
      with the provisioning server and looks for deployed services by
      devices. Moreover, the provisioning server can verify the complete
      authorization, admission, and resource control of any device's
      services. Whereas, if any other constrained devices (ex. air
      conditioner) searches for services hosted by other constrained
      device (as explained for scenario 1) MUST interact with the RD
      server as shown in Fig 15. Here, initially the device queries for
      all services that are hosted by other devices, then it searches
      within the domain for specific service, its SRV info, and path to
      the hosted service. Before sending a request, it MUST establish a
      secure channel between these two nodes [draft-schmitt-ace-
      twowayauth-for-iot].








 


Vasu K                    Expires Oct 15, 2016                 [Page 19]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       +---------------+                                   +----------+
       | Device        |                                   | RD Server|
       | (aircondit    |                                   |          |
       |   ioner)      |                                   |          |
       +-----+---------+                                   +-------+--+
             |                                                     |
             |  GET /rd-lookup/gp?d=example.com                `.  |
             +---------------------------------------------------`.:
             |                                                 .-' |
             | .'2.05 Content <gp="thermostat">                    |
             ::----------------------------------------------------+
             | `-.                                                 |
             |   GET /rd-lookup/ep?gp=thermostat                `. |
             +----------------------------------------------------::
             |                                                  .' |
             | .'2.05 Content <Node1> <Node2>                      |
             ::----------------------------------------------------+
             | `.                                                  |
             |                                                     |
             | GET /rd-lookup/ep?et=temperature&gp=thermostat   `. |
             +----------------------------------------------------`.
             |                                                  .' |
             |                                                     |
             | .'2.05 Content <coap://ip:port>;ep="Node1"          |
             ::----------------------------------------------------+
             | `-.                                                 |
             |                                                     |
            Fig. 15 Search for services by device                   



6.6 Service request and response

      In scenario 1 (as shown in Fig 2), service request and response
      MUST use coap based communication to access the service as shown
      in Fig 16. Before sending a request, it MUST establish a secure
      channel between these two nodes [draft-schmitt-ace-twowayauth-for-
      iot]. Suppose, the constrained client device (for ex.
      airconditioner) want to access the service hosted by another
      constrained device (for ex. thermostat), then the client device
      MUST send a coap based GET request to thermostat. Then, this
      device (thermostat) SHOULD send a POST request to provision this
      service request with the provisioning server by sending clients
      <IP:port>. Based on the clients <IP:port>, the provisioning server
      MUST find the client (ex. airconditioner) details such as service
      information, group, domain, and type details. 


 


Vasu K                    Expires Oct 15, 2016                 [Page 20]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      +------------+              +-------------+          +-----------+
      |Airconditi  |              |Thermostat   |          |Provision  |
      |oner        |              | (IP1)       |          |ining Server
      | (IP2)      |              |             |          | (IP3)     |
      +-----+------+              +------+------+          +--------+--+
            |                            |                          |
            |coap://thermostat.        `.|                          |
            +----------------------------::                         |
            |    example.com/temp     .' |POST /thermostat       `. |
            |                            +-------------------------::
            |                            |HOST thermostat.ps.    .' |
            |                            |             example.com  |
            |                            |Content-Type: application/txt
            |                            |{ SRC: <IP1,port>         |
            |                            |  DST: <IP3,port>         |
            |                            |  Client: <IP2,port> }    |
            |                            |                          | 
            |                            |  +--------------------------+
            |                            |  |Check for Admission,      |
            |                            |  |ResourceControl of thermost
            |                            |  |for airconditioner        |
            |                            |  +--------------------------+
            |                            |                          |
            |                            | .'2.00 OK { Permit/Deny }|
            | .'URI-Path: temp CON 200    ::------------------------+
            ::---------------------------+ `-.                      |
            | `.("thermostat","aaaa::212.|                          |
            |  7402.2.202","temp",27)    |                          |
            |                            |                          |
         Fig. 16 Request/Response within Constrained Environment


      Once the client is identified, the provisioning server MUST check
      for authorization, admission and resource control policies of
      hosted service (ex. thermostat). Once the service request is
      authorized to access then the URI-Path for hosted service along
      with the value is sent as a coap response to client device (air
      conditioner). Here, the request is conditional i.e. based on the
      resource control policies of a resource (such as thermostat) for a
      client (airconditioner), the permissions are given to access the
      resource.







 


Vasu K                    Expires Oct 15, 2016                 [Page 21]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      +-------------+               +------------+           +---------+
      |             |               |Provision   |           |         |
      | Client      |               |ining Server|           |Thermostat
      |             |               |            |           |         |
      +-----+-------+               +-----+------+           +------+--+
            |                             |                         |
            |http://thermostat.        `. |                         |
            +----------------------------::                         |
            |  example.com/temp        .' |                         |
            |            +-----------------------------+            |
            |            |Check for Admission,         |            |
            |            |Resource Control of thermostat            |
            |            |for airconditioner           |            |
            |            +-----------------------------+            |
            |                             |                         |
            |                             | coap://thermostat.   `. |
            |                             +------------------------::
            |                             |example.com/temp      .' |
            |                             |                         |
            |                             |                         |
            |                             | .'URI-Path: temp CON 200|
            |                             ::------------------------+
            |                             | `.                      |
            | .' HTTP/1.1 200 OK          |                         |
            ::----------------------------+                         |
            | `. Temperature: 27          |                         |
            |                             |                         |
          Fig. 17 Request/Response from outside Constrained Environment


      Service request and response in scenario 2 (as shown in Fig 3),
      uses simple http based communication to access the service from
      the PS. Provisioning Server then sends a coap based GET request to
      the ultimate device that hosts service. Before sending this
      request to the actual device for service, PS authorizes the
      service request. Once, the service request is authorized to
      access, then the URI-path for hosted service along with the value
      is sent as HTTP response to client device. PS can implement a
      reverse proxy case for HTTP-CoAP protocol translation defined in
      [draft-ietf-core-http-mapping].


      ------------------HTTP begin -------------------------------------
      HTTP POST 
      Request:
      POST /thermostat   /HTTP/1.1
      HOST thermostat.example.com
      Content-Type:  application/x-www-form-urlencoded
 


Vasu K                    Expires Oct 15, 2016                 [Page 22]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      Content-Length:  length
      licenseID=string & content=string & paramsXML=string

      Response:
      HTTP/1.1   200 OK
      Content-Type:  text/xml; charset=utf-8
      Content-Length:  length
      <?xml version="1.0" encoding="utf-8"?>
      <string xmlns="http://xyz.com/">
      string
      </string>

      ------------------HTTP end  -------------------------------------

      ------------------ REST via HTTP begin --------------------------
      REST via HTTP POST 
      Request:
      POST /thermostat   /HTTP/1.1
      HOST thermostat.example.com
      Content-Type:  application/x-www-form-urlencoded
      Content-Length:  length

      licenseID=string & content=string & paramsXML=string

      Response:
      HTTP/1.1   200 OK
      Content-Type:  text/xml; charset=utf-8
      Content-Length:  length

      string

      ------------------REST via HTTP end -----------------------------

      ------------------SOAP begin ------------------------------------

      SOAP 1.2 
      Request:
      POST /Thermostat   /HTTP/1.1
      HOST: www.example.org
      Content-Type:  application/soap+xml; charset=utf-8
      Content-Length:  length

      <?xml version="1.0"?>
      <soap:envelop>
      Xmlns:soap=http://www.w3.org/2001/12/soap-envelop
      Soap:encodingStyle=http://www.w3.org/2001/12/soapencoding>
      <soap:body xmlns: m="http://www.myhome.org/thermostat">
      <m:GetTemperature>
 


Vasu K                    Expires Oct 15, 2016                 [Page 23]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      <m:thermostat>1</m:thermostat>
      </m:GetTemperature>
      </soap:body>
      </soap:envelop>

      Response:
      HTTP/1.1 200 OK
      Content-Type:  application/soap+xml; charset=utf-8
      Content-Length:  length

      <?xml version="1.0"?>
      <soap:envelop>
      Xmlns:soap=http://www.w3.org/2001/12/soap-envelop
      Soap:encodingStyle=http://www.w3.org/2001/12/soapencoding>
      <soap:body xmlns: m="http://www.example.org/thermostat">
      <m:GetTemperatureResponse>
      <m:temperature>27.8</m:temperature>
      </m:GetTemperatureResponse>
      </soap:body>
      </soap:envelop>

      ------------------SOAP end ----------------------------------
7 Alternative Solution

7.1 System Architecture

      The system architecture is as shown in the Fig 18, the thing
      (device) always registers its service with RD server. CA verifies
      registered service with RD server and configures policies at
      provisioning server for resource access by various other devices
      or clients. The provisioning server can access any resource from
      the RD server and also has right to provision any device or client
      before assigning the resource. This provisioning server not only
      authorizes the client, it also controls the resource access with
      the configured policies with various non security parameters. The
      client or device should always talk to provisioning sever for
      resource access. Once authorized and provisioned completely it is
      allowed to access the resource. The following interfaces are
      defined in the architecture.
      IF-a: register service (coap)
      IF-b: verify service (coap)
      IF-c: configure policies (coap or http)
      IF-d: obtain resource (coap)
      IF-e: assign resource (coap or http)




 


Vasu K                    Expires Oct 15, 2016                 [Page 24]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


                                                         +-------+
                                                         |Thing  |
                                                         |(Server|
                                                         +---+---+
                                                             |
                                                             |IF-a
                                                             |
                                                             |
                    +-------+        +--------+           +--+---+
                    |       |        |        |           |      |
                    |Client |________|        |___________|      |
                    |(Thning| IF-e   |  PS    |   IF-d    | RD   |
                    |/Client)        |        |           |      |
                    +-------+        +-------++           +-+----+
                                              \            /
                                          IF-c \          /
                                                \        /IF-b
                                                 \      /
                                               +--+----+-+
                                               |         |
                                               |   CA    |
                                               |         |
          PS-Provisioning Server               +---------+
          RD-Resource Directory
          CA-Commissioning Agent

                Fig 18. System Architecture


7.2 Service Request

      The device either constrained (ex. air conditioner) or non-
      constrained (ex. mobile phone) that searches for services hosted
      by other constrained device MUST interact with the Provisioning
      Server (PS) as shown in Fig 19. Here, the device queries to the
      provisioning server by query options for example, "op=read &
      rt=temp", which means "obtain resource with read operation".
      Before sending a request, it MUST establish a secure channel
      between these two nodes [draft-schmitt-ace-twowayauth-for-iot].
      Whenever the provisioning server receives the resource request
      from device or client, it MUST find the group to which the device
      or client belongs to from the preconfigured information. 






 


Vasu K                    Expires Oct 15, 2016                 [Page 25]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


       +-------------+       +-------------+      +--------------+
       |Device       |       |             |      |              |
       |(AirCondition|       |Provisioning |      |RD Server     |
       |er)          |       |Server       |      |              |
       |             |       |             |      |              |
       +----|--------+       +-------|-----+      +--------|-----+
            |GET                     |                     |
            |coap://ps.example.com/c |                     |
            |ore.ps.search/ep?op=rea |                     |
            |d&rt=temp               \                     |
            --------------------------/                    |
            |                        /                     |
            |           +-------------------------+        |
            |           |            |            |        |
            |           | find the group to which |        |
            |           | the device belongs to   |        |
            |           +-------------------------+        |
            |                        |GET                  |
            |                        |/rd-lookup/res?rt=  \|
            |                        -temp-----------------/
            |                        |                    /|
            |                        |                   / |
            |                        | / <coap://[aaaa::212.7
            |                        |/  402.2.202]:61616/tem
            |                        ---p>;-ep=node1;------
            |                        |  rt=temp;......     |
            |                        |                     |
            |                        |                     |
            |        +-----------------------------+       |
            |        |  Parse the conditional      |       |
            |        |  statements for each        |       |
            |        |  resource obtained          |       |
            |        +-----------------------------+       |
            |                        |                     |
            |                        |                     |
            |       +------------------------------+       |
            |       |Obtain the most suited        |       |
            |       |resource from the list and    |       |
            |       |increase the count field in   |       |
            |       |AC. And assign that resource  |       |
            |       +------------------------------+       |
            |   <coap://[aaaa::212.74|                     |
            |// 02.2.202]:61616/temp>|                     |
             \-----------------------|                     |
            | \                      |                     |
              Fig 19. Search for Service


 


Vasu K                    Expires Oct 15, 2016                 [Page 26]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      Once obtaining the group information of device or client, PS
      SHOULD do rt-lookup query to RD server. After obtaining the
      resource information, the PS MUST parse the conditional statements
      for each resource to detect most suited resource to be assigned to
      the client or device. The method for detecting the best resource
      can use any well-know MADM or fuzzy logic techniques which is out
      of scope of the present document. And finally, the provisioning
      server should increase the count field in admission control, and
      assign the resource to device/client. Once the service request is
      authorized and provisioned to control the resource, the device or
      client can obtain the resource directly as shown in Fig 20.


        +---------------+                     +--------------+
        |               |                     |              |
        |Device         |                     |Thermostat    |
        |(Airconditione |                     |              |
        |r              |                     |              |
        |               |                     |              |
        +-------|-------+                     +-------|------+
                |                                     |
                |                                     |
                |                                     |
                |coap://[aaaa::212.7402.2.202]:61     |
                |616/temp                           \ |
                -------------------------------------/-
                |                                   / |
                |                                  /  |
                |                                     |
                |                                     |
                |                                     |
                |                                     |
                |  /                                  |
                |//  { et:"thermostat"; "temp":27}    |
                /--------------------------------------
                                                      |
                |\                                    |
                |                                     |
                |                                     |

              Fig 20. Service Request and Response

8  Security Considerations

      Security level for message authentication is out of scope of the
      present document. However, the following security consideration
      needs to be considered for the present proposed method. Services
      that run over UDP are unprotected and vulnerable to unknowingly
 


Vasu K                    Expires Oct 15, 2016                 [Page 27]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


      become part of a DDoS attack as UDP does not require return
      routability check. Therefore, an attacker can easily spoof the
      source IP of the target entity and send requests to such a service
      which would then respond to the target entity. The TLS/DTLS based
      security solution can be considered for secure message
      communication.


9  IANA Considerations

      core.ps and "core.ps.search" to be registered with the resource
      type registry defined by [RFC6690]. Under "CoRE Parameters" , a
      new query parameter needs to be defined as shown below. The query
      parameter MUST be a valid URI query key [RFC3986].

       +--------+---------+----------+---------+
       |Name    | Query   |Validity  |Description
       |________|_________|__________|_________|
       |        |         |          |Used for |
       |Operatio|  op     | string   |operation|
       |       n|         |          |on device|
       |        |         |          |         |
       +--------+---------+----------+---------+


10  References

10.1  Normative References


10.2  Informative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
      Constrained-Node Networks", RFC 7228, May 2014.

   [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
      "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC
      4944, September 2007.

   [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
      Application Protocol (CoAP)", RFC 7252, June 2014.

   [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
      Format", RFC 6690, August 2012.

 


Vasu K                    Expires Oct 15, 2016                 [Page 28]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


   [draft-ietf-core-resource-directory] Shelby, Z., and Bormann, C.,
      "CoRE Resource Directory", draft-ietf-core-resource-directory-02
      (work in progress), November 2014.

   [draft-gerdes-ace-actors] Gerdes, S., "Actors in the ACE
      Architecture", draft-gerdes-ace-actors-03 (work in progress),
      March 2015.

   [draft-gerdes-ace-dcaf-authorize] Gerdes, S., Bergmann, O., Bormann,
      C., "Delegated CoAP Authentication and Authorization Framework
      (DCAF)", draft-gerdes-ace-dcaf-authorize-02, March 2015.

   [draft-bormann-core-ace-aif] Bormann, C., "An Authorization
      Information Format (AIF) for ACE", draft-bormann-core-ace-aif-oo,
      January 2014.

   [draft-schmitt-ace-twowayauth-for-iot] Schmitt, C., Stiller, B.,
      "Two-way Authentication for IoT", draft-schmitt-ace- twowayauth-
      for-iot-01, December 2014.

   [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
      Security", RFC 6347, January 2012.

   [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.2", RFC
      5246, August 2008.

   [draft-ietf-core-http-mapping] Castellani, A., Loreto, S., Rahman,
      A., Fossati, T., and Dijk, E., "Guidelines for HTTP-CoAP Mapping
      Implementations", draft-ietf-core-http-mapping-05, (work in
      progress), Oct 2015.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
      Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI
      10.17487/RFC3986, January 2005, <http://www.rfc-
      editor.org/info/rfc3986>.

   [draft-seitz-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem,
      E., Erdtman, S., Tschofenig, H., "Authorization for the Internet
      of Things using OAuth 2.0", draft-seitz-ace-oauth-authz-00, (work
      in progress), Oct 2015.








 


Vasu K                    Expires Oct 15, 2016                 [Page 29]

Internet-Draft       Access Privilege Provisioning        April 15, 2016


11  Acknowledgements


   Special thanks to Amit Kumar S,Zhengfei, Fubaicheng, zuojing,
   Yangjun,Vijayachandran Mariappan, Shashidhar C Shekar,
   Jayaraghavendran K, Ajay Sankar, Puneet Balmukund Sharma, and Rabi
   Narayan Sahoo for extensive comments and contributions that improved
   the text. 

   Special Thanks to Caozhen, Hedanping (Ana), Behcet Sarikaya, and
   Carsten Bormann for helpful comments and discussions that have shaped
   the document. Thanks to IETF 94th participants to give valuable
   comments that shaped the draft with clear information.

Authors' Addresses


   Vasu K
   Huawei Technologies
   Bangalore
   India

   EMail: vasu.kantubukta@huawei.com



   Rahul A Jadhav
   Huawei Technologies
   Bangalore
   India

   EMail: rahul.jadhav@huawei.com


   yangneng
   Huawei Technologies
   Shenzhen
   China

   EMail: yangneng@huawei.com











Vasu K                    Expires Oct 15, 2016                 [Page 30]