[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
ACE Working Group                                         Hyunsik Yang
Internet Draft                                            Youngki Park
Intended status: Informational                            Younghan Kim
Expires: January 2016                              Soongsil University
                                                           Namhi Kang
                                                                HERIT
                                                          July 6, 2015

       Authentication architecture for a group of constrained devices
                      draft-yang-ace-groupauth-00.txt


Abstract

   Constrained devices have a limitation in adapting various general
   cryptography mechanisms since they have limited processing power,
   storage space and transmission capacities. Moreover, in an
   environment that has a large number of constrained devices, the
   device authentication and authorization procedure causes serious
   burdens. Therefore, this draft proposes a group authentication
   mechanism to solve existing problems.




Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November 10,
   2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   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.




Yang, et al.           Expires January 6, 2016                [Page 1]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


   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/ietf/1id-abstracts.txt

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

   This Internet-Draft will expire on January 6, 2016.

Copyright Notice

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





















Yang, et al.           Expires January 6, 2016                [Page 2]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015




Table of Contents


   1. Introduction ................................................ 4
      1.1. Terminology ............................................ 4
   2. Use cases ................................................... 5
         2.1.1. Wearable devices................................... 5
         2.1.2. Requirements for wearable devices ................. 5
         2.1.3. Mobile sink for isolated sensor environment........ 6
         2.1.4. Requirements for mobile sink ...................... 6
   3. Group authentication architecture and procedures ............ 6
      3.1. Architecture ........................................... 6
      3.2. Group authentication procedure ......................... 7
         3.2.1. Device registration................................ 7
         3.2.2. Resource discovery................................. 8
      3.3. Group authentication procedure (inbound) ............... 8
   4. Consideration ............................................... 9
   5. Security Considerations...................................... 9
   6. IANA Considerations ........................................ 10
   7. Conclusion ................................................. 10
   8. References ................................................. 10
      8.1. Normative References................................... 10
      8.2. Informative References................................. 10
   9. Acknowledgments ............................................ 10






















Yang, et al.           Expires January 6, 2016                [Page 3]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015




 1. Introduction

   Currently, many constrained devices are used for various applications
   in various fields; therefore, their authentication issues should be
   considered carefully. The general authentication method is based on
   one-by-one communication (i.e. unicast). However, there will be
   burdens in a scenario, where a node needs to authenticate large
   number of devices at the same time. Moreover, when a lot of devices
   are located in one place, it will cause a bottleneck. Furthermore,
   constrained devices have a limitation in adopting various general
   cryptography mechanisms since they have limited processing power,
   storage space and transmission capacities.

   This document considers various use cases for authentication and
   authorization in constrained environments and proposes a mechanism
   and a procedure for group authentication.

   Based on the use cases, this document also defines a group entity
   functionality and initiate procedure when operator of each device
   wants to get mutual authentication.

1.1. 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 RFC-2119 [RFC2119].

   Group

     Users can make a group based on application usage or authentication
     method.

   Group cluster header

     Group cluster header is one of the group members and is a
     representative of a specific group.

   Group agent

     Group agent can manage several groups and it also has a required
     function for group authentication.

   Group ID

     It is a unique ID that identifies a specific group.


Yang, et al.           Expires January 6, 2016                [Page 4]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


   Group shared key

    It is used by the device and group agent to verify each other.



 2. Use cases

   Group authentication enables a node to authenticate all devices in a
   group at once. Group authentication can reduce both computing and
   signaling cost of the authentication procedure and enhance security
   of the constrained devices.

   This section describes use cases that prefer to use a group based
   authentication rather than one-by-one authentication. Based on the
   use cases, we list several requirements and considerations.

2.1.1. Wearable devices

   Suppose that Alice has four devices; a heartbeat-monitoring device, a
   blood pressure-monitoring device, smart glasses for virtual screen,
   and a smart ring to control the virtual screen.

   When Alice arrives in her workplace, the smart glasses and smart ring
   may need to get data from a database server or IT management server
   of the company, and the server may need to update these devices'
   firmware. Both of the scenarios require mutual authentication since
   the company servers and Alice's devices must verify each other. After
   Alice leaves the office, Alice goes to a hospital to check her health
   status. When she arrives at the hospital and meets a doctor, if the
   doctor wants to change the configuration in a device or get her
   health data, at this time, authentication is required.



2.1.2. Requirements for wearable devices

   Authentication mechanism is required for every device to verify its
   communication entity in advance of data exchange. The authentication
   mechanism would be changed according to device capability.

   Group key should be shared to verify identities between devices and
   group agent.

   The discovery procedure between group agent and corresponding nodes
   is out of scope.



Yang, et al.           Expires January 6, 2016                [Page 5]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015




2.1.3. Mobile sink for isolated sensor environment

   In Wireless Sensor Network, Mobile sink, which has a function
   allowing nodes to move anywhere, is to be a solution for aggregating
   data. Especially, mobile sink is used for gathering sensor data from
   deployed sensors, where they are located in isolated environment such
   as the heart of a mountain or the deep sea. Based on sensor
   characteristics, user can make a group such as a humidity group or a
   temperature group and others. In some scenarios, authentication is
   required for secure communication between mobile sink and sensor node.
   For that, a mobile sink can authenticate its corresponding group
   cluster header based on the group authentication mechanism.

2.1.4. Requirements for mobile sink

   Group key should be shared to verify identities between sensor and
   mobile sink.

   Based on group information, mobile sink can request message to group
   cluster header.

   The discovery procedure between group agent and corresponding nodes
   is not necessary.



 3. Group authentication architecture and procedures



3.1. Architecture

   As shown in figure 1, the proposed group authentication architecture
   is hierarchically constructed. Users (application user or service
   provider) make one or more groups based on application policy or
   service goal. For example, there might be a group of devices for
   healthcare service and a group of devices for working, etc. The group
   agent manages the groups. Also, in a group, one device can be
   selected as a group cluster header which delegates authentication for
   other devices in his group. We note here that a device can belong to
   one or multiple groups (see the device 2 in figure 1). Group agent
   has a management function and it communicates with its corresponding
   nodes. In the figure 1, CN indicates a corresponding node.




Yang, et al.           Expires January 6, 2016                [Page 6]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


   ************************************************
   *    +-------+                                 *
   *    +device1+       +----------------------+  *
   *    +-------+       +     device 2         +  *
   *                    +(group cluster header)+--*-----+
   *                    +----------------------+  *     |
   *  ##############                              *     |
   *  #             #                             *     |
   *  # +-------+    # ****************************+-----------+    +--+
   *  # +device2+     *                            +group agent+<-->|CN|
   *  # +-------+    * ##########################  +-----------+    +--+
   *  #             *                           #       |
   *****************                            #       |
      #                 +--------------------+  #       |
      # +-------+       +group cluster header+--#-------+
      # +device3+       +--------------------+  #
      # +-------+                               #
      ###########################################


                Figure 1  Group Authentication Architecture

3.2. Group authentication procedure

   In this document, we just consider on the inbound case as an initial
   version of this draft. That is, we define a procedure when a
   corresponding node (CN) sends a request to a group of devices. Our
   procedure is divided into two phases. The first phase is the device
   registration with group agent; the second phase is the group
   authentication.


3.2.1. Device registration

   As discussed in the former section, we assume that groups are made by
   users, and each group has a header that is the representative device
   of the group. The header device can be pre-configured by users or can
   be selected in a dynamic fashion. The way to dynamically decide a
   header device is out of scope of the current document. When a group
   header is decided, the header device and its corresponding group
   agent share a secret key each other. Also, each group header forwards
   the secret key to its group devices through a secure channel.

   Alternatively, a group agent performs authentication procedures with
   a representative header of a group of devices. The authentication
   between the group agent and the header device can be done by a


Yang, et al.           Expires January 6, 2016                [Page 7]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


   general asymmetric key based method (i.e. RawPublic Key or
   Certificate based mode of CoAP over DTLS binding).



3.2.2. Resource discovery

   Corresponding nodes should know their group information to send group
   based request message to the group agent. Therefore, we should define
   procedure of gathering group information based on CoAP[RFC7252]. When
   a corresponding node sends group information request messages to the
   group agent like a resource discovery message in CoAP, the group
   agent replies to the corresponding node with group information.

3.3. Group authentication procedure (inbound)

   The general procedure of message flows from corresponding nodes to
   devices is described below. A corresponding node sends the
   authentication request message to its group agents. After receiving
   the authentication request message, the group agent verifies the
   corresponding node identity. After authentication, the corresponding
   node sends the group discovery message to the group agent.
   Corresponding nodes that need group information from the group agent
   sends a request message (information, configuration) to the group
   agent with the group ID. When a group agent receives the request
   message, it looks up group ID information and forwards it to the
   group cluster header that corresponds to the received group ID. The
   group cluster header verifies the group agent identity and sends a
   request message to devices in its group.



















Yang, et al.           Expires January 6, 2016                [Page 8]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


    Device1(A)    Device2(A)     Group Cluster      Group Agent      CN
                   (GCH)           (A group)
        |            |                 |                |            |
        |            |                 |                |<-Auth Req--|
        |            |                 |                |            |
        |            |                 |       Authentication of     |
        |            |                 |                CN           |
        |            |                 |                |            |
        |            |                 |                |<-Group Info|
        |            |                 |                |    Reg     |
        |            |                 |                |            |
        |            |                 |                |Group Info->|
        |            |                 |                |            |
        |            |                 |                |<--Req Msg--|
        |            |                 |                | (group A)  |
        |            |                 |                |            |
        |            |                 |             Mapping         |
        |            |                 |              group          |
        |            |                 |                |            |
        |            |                 |<----Req Msg----|            |
        |            |                 |                |            |
        |            |         Authentication of        |            |
        |            |                 GA               |            |
        |            |                 |                |            |
        |            |<----Req Msg-----|                |            |
        |            |                 |                |            |
        |            |                 |                |            |
        |<---------Req Msg-------------|                |            |
        |            |                 |                |            |

                  Figure 2 Group Authentication Procedure

 4. Consideration

   In this document, we define necessary functions and procedures when
   corresponding nodes send a request message to group devices. In
   future work, we will refine and list more use cases requiring the
   group authentication and define a function, entity, procedure and so
   on. Moreover, we consider key management and dynamic key registration
   within the group.



 5. Security Considerations

   TBD



Yang, et al.           Expires January 6, 2016                [Page 9]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


 6. IANA Considerations

   This document has no IANA actions.



 7. Conclusion

   In this document, we described use cases and an efficient way to
   authenticate an entity for a group communication. Based on the use
   cases, we will add more functions and procedures.



 8. References

8.1. Normative References

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

   [I.D.ietf-ace-usecases-04]

            L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S.
             Kumar, "ACE use cases", draft-ietf-ace-usecases-04, June 04,
             2015.

   [I.D.ietf-dice-profile-13]

            H. Tschofenig, Ed., T. Fossati," A TLS/DTLS Profile for the
             Internet of Things", draft-ietf-dice-profile-13, June 11,
             2015.

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

8.2. Informative References



9. Acknowledgments








Yang, et al.           Expires January 6, 2016               [Page 10]


Internet-Draft       draft-yang-ace-groupauth-00             July 2015


   Authors' Addresses

   Hyunsik Yang
     Soongsil University
     369, Sangdo-ro, Dongjak-gu,
     Seoul 156-743, Korea
     Email: yangun@dcn.ssu.ac.kr


   Youngki Park
     Soongsil University
     369, Sangdo-ro, Dongjak-gu,
     Seoul 156-743, Korea
     Email: ykpark@dcn.ssu.ac.kr


   Namhi Kang
      HERIT Corporation
      613, Seolleung-ro, Gangnam-gu,
      Seoul 135-833, Korea
      Email: kang@herit.net
      URI:  http://www.herit.net


   Younghan Kim
     Soongsil University
     369, Sangdo-ro, Dongjak-gu,
     Seoul 156-743, Korea
     Email: younghak@ssu.ac.kr



















Yang, et al.           Expires January 6, 2016               [Page 11]