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]