idnits 2.17.1 draft-yang-ace-groupauth-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) ** There are 5 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2015) is 3218 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC2119' on line 123 looks like a reference -- Missing reference section? 'RFC7252' on line 357 looks like a reference -- Missing reference section? 'RFC7228' on line 372 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ACE Working Group Hyunsik Yang 2 Internet Draft Youngki Park 3 Intended status: Informational Younghan Kim 4 Expires: January 2016 Soongsil University 5 Namhi Kang 6 HERIT 7 July 6, 2015 9 Authentication architecture for a group of constrained devices 10 draft-yang-ace-groupauth-00.txt 12 Abstract 14 Constrained devices have a limitation in adapting various general 15 cryptography mechanisms since they have limited processing power, 16 storage space and transmission capacities. Moreover, in an 17 environment that has a large number of constrained devices, the 18 device authentication and authorization procedure causes serious 19 burdens. Therefore, this draft proposes a group authentication 20 mechanism to solve existing problems. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, and it may not be 27 published except as an Internet-Draft. 29 This document may contain material from IETF Documents or IETF 30 Contributions published or made publicly available before November 10, 31 2008. The person(s) controlling the copyright in some of this 32 material may not have granted the IETF Trust the right to allow 33 modifications of such material outside the IETF Standards Process. 34 Without obtaining an adequate license from the person(s) controlling 35 the copyright in such materials, this document may not be modified 36 outside the IETF Standards Process, and derivative works of it may 37 not be created outside the IETF Standards Process, except to format 38 it for publication as an RFC or to translate it into languages other 39 than English. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF), its areas, and its working groups. Note that 43 other groups may also distribute working documents as Internet-Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 50 The list of current Internet-Drafts can be accessed at 51 http://www.ietf.org/ietf/1id-abstracts.txt 53 The list of Internet-Draft Shadow Directories can be accessed at 54 http://www.ietf.org/shadow.html 56 This Internet-Draft will expire on January 6, 2016. 58 Copyright Notice 60 Copyright (c) 2015 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents carefully, 67 as they describe your rights and restrictions with respect to this 68 document. Code Components extracted from this document must include 69 Simplified BSD License text as described in Section 4.e of the Trust 70 Legal Provisions and are provided without warranty as described in 71 the Simplified BSD License. 73 Table of Contents 75 1. Introduction ................................................ 4 76 1.1. Terminology ............................................ 4 77 2. Use cases ................................................... 5 78 2.1.1. Wearable devices................................... 5 79 2.1.2. Requirements for wearable devices ................. 5 80 2.1.3. Mobile sink for isolated sensor environment........ 6 81 2.1.4. Requirements for mobile sink ...................... 6 82 3. Group authentication architecture and procedures ............ 6 83 3.1. Architecture ........................................... 6 84 3.2. Group authentication procedure ......................... 7 85 3.2.1. Device registration................................ 7 86 3.2.2. Resource discovery................................. 8 87 3.3. Group authentication procedure (inbound) ............... 8 88 4. Consideration ............................................... 9 89 5. Security Considerations...................................... 9 90 6. IANA Considerations ........................................ 10 91 7. Conclusion ................................................. 10 92 8. References ................................................. 10 93 8.1. Normative References................................... 10 94 8.2. Informative References................................. 10 95 9. Acknowledgments ............................................ 10 97 1. Introduction 99 Currently, many constrained devices are used for various applications 100 in various fields; therefore, their authentication issues should be 101 considered carefully. The general authentication method is based on 102 one-by-one communication (i.e. unicast). However, there will be 103 burdens in a scenario, where a node needs to authenticate large 104 number of devices at the same time. Moreover, when a lot of devices 105 are located in one place, it will cause a bottleneck. Furthermore, 106 constrained devices have a limitation in adopting various general 107 cryptography mechanisms since they have limited processing power, 108 storage space and transmission capacities. 110 This document considers various use cases for authentication and 111 authorization in constrained environments and proposes a mechanism 112 and a procedure for group authentication. 114 Based on the use cases, this document also defines a group entity 115 functionality and initiate procedure when operator of each device 116 wants to get mutual authentication. 118 1.1. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC-2119 [RFC2119]. 124 Group 126 Users can make a group based on application usage or authentication 127 method. 129 Group cluster header 131 Group cluster header is one of the group members and is a 132 representative of a specific group. 134 Group agent 136 Group agent can manage several groups and it also has a required 137 function for group authentication. 139 Group ID 141 It is a unique ID that identifies a specific group. 143 Group shared key 145 It is used by the device and group agent to verify each other. 147 2. Use cases 149 Group authentication enables a node to authenticate all devices in a 150 group at once. Group authentication can reduce both computing and 151 signaling cost of the authentication procedure and enhance security 152 of the constrained devices. 154 This section describes use cases that prefer to use a group based 155 authentication rather than one-by-one authentication. Based on the 156 use cases, we list several requirements and considerations. 158 2.1.1. Wearable devices 160 Suppose that Alice has four devices; a heartbeat-monitoring device, a 161 blood pressure-monitoring device, smart glasses for virtual screen, 162 and a smart ring to control the virtual screen. 164 When Alice arrives in her workplace, the smart glasses and smart ring 165 may need to get data from a database server or IT management server 166 of the company, and the server may need to update these devices' 167 firmware. Both of the scenarios require mutual authentication since 168 the company servers and Alice's devices must verify each other. After 169 Alice leaves the office, Alice goes to a hospital to check her health 170 status. When she arrives at the hospital and meets a doctor, if the 171 doctor wants to change the configuration in a device or get her 172 health data, at this time, authentication is required. 174 2.1.2. Requirements for wearable devices 176 Authentication mechanism is required for every device to verify its 177 communication entity in advance of data exchange. The authentication 178 mechanism would be changed according to device capability. 180 Group key should be shared to verify identities between devices and 181 group agent. 183 The discovery procedure between group agent and corresponding nodes 184 is out of scope. 186 2.1.3. Mobile sink for isolated sensor environment 188 In Wireless Sensor Network, Mobile sink, which has a function 189 allowing nodes to move anywhere, is to be a solution for aggregating 190 data. Especially, mobile sink is used for gathering sensor data from 191 deployed sensors, where they are located in isolated environment such 192 as the heart of a mountain or the deep sea. Based on sensor 193 characteristics, user can make a group such as a humidity group or a 194 temperature group and others. In some scenarios, authentication is 195 required for secure communication between mobile sink and sensor node. 196 For that, a mobile sink can authenticate its corresponding group 197 cluster header based on the group authentication mechanism. 199 2.1.4. Requirements for mobile sink 201 Group key should be shared to verify identities between sensor and 202 mobile sink. 204 Based on group information, mobile sink can request message to group 205 cluster header. 207 The discovery procedure between group agent and corresponding nodes 208 is not necessary. 210 3. Group authentication architecture and procedures 212 3.1. Architecture 214 As shown in figure 1, the proposed group authentication architecture 215 is hierarchically constructed. Users (application user or service 216 provider) make one or more groups based on application policy or 217 service goal. For example, there might be a group of devices for 218 healthcare service and a group of devices for working, etc. The group 219 agent manages the groups. Also, in a group, one device can be 220 selected as a group cluster header which delegates authentication for 221 other devices in his group. We note here that a device can belong to 222 one or multiple groups (see the device 2 in figure 1). Group agent 223 has a management function and it communicates with its corresponding 224 nodes. In the figure 1, CN indicates a corresponding node. 226 ************************************************ 227 * +-------+ * 228 * +device1+ +----------------------+ * 229 * +-------+ + device 2 + * 230 * +(group cluster header)+--*-----+ 231 * +----------------------+ * | 232 * ############## * | 233 * # # * | 234 * # +-------+ # ****************************+-----------+ +--+ 235 * # +device2+ * +group agent+<-->|CN| 236 * # +-------+ * ########################## +-----------+ +--+ 237 * # * # | 238 ***************** # | 239 # +--------------------+ # | 240 # +-------+ +group cluster header+--#-------+ 241 # +device3+ +--------------------+ # 242 # +-------+ # 243 ########################################### 245 Figure 1 Group Authentication Architecture 247 3.2. Group authentication procedure 249 In this document, we just consider on the inbound case as an initial 250 version of this draft. That is, we define a procedure when a 251 corresponding node (CN) sends a request to a group of devices. Our 252 procedure is divided into two phases. The first phase is the device 253 registration with group agent; the second phase is the group 254 authentication. 256 3.2.1. Device registration 258 As discussed in the former section, we assume that groups are made by 259 users, and each group has a header that is the representative device 260 of the group. The header device can be pre-configured by users or can 261 be selected in a dynamic fashion. The way to dynamically decide a 262 header device is out of scope of the current document. When a group 263 header is decided, the header device and its corresponding group 264 agent share a secret key each other. Also, each group header forwards 265 the secret key to its group devices through a secure channel. 267 Alternatively, a group agent performs authentication procedures with 268 a representative header of a group of devices. The authentication 269 between the group agent and the header device can be done by a 270 general asymmetric key based method (i.e. RawPublic Key or 271 Certificate based mode of CoAP over DTLS binding). 273 3.2.2. Resource discovery 275 Corresponding nodes should know their group information to send group 276 based request message to the group agent. Therefore, we should define 277 procedure of gathering group information based on CoAP[RFC7252]. When 278 a corresponding node sends group information request messages to the 279 group agent like a resource discovery message in CoAP, the group 280 agent replies to the corresponding node with group information. 282 3.3. Group authentication procedure (inbound) 284 The general procedure of message flows from corresponding nodes to 285 devices is described below. A corresponding node sends the 286 authentication request message to its group agents. After receiving 287 the authentication request message, the group agent verifies the 288 corresponding node identity. After authentication, the corresponding 289 node sends the group discovery message to the group agent. 290 Corresponding nodes that need group information from the group agent 291 sends a request message (information, configuration) to the group 292 agent with the group ID. When a group agent receives the request 293 message, it looks up group ID information and forwards it to the 294 group cluster header that corresponds to the received group ID. The 295 group cluster header verifies the group agent identity and sends a 296 request message to devices in its group. 298 Device1(A) Device2(A) Group Cluster Group Agent CN 299 (GCH) (A group) 300 | | | | | 301 | | | |<-Auth Req--| 302 | | | | | 303 | | | Authentication of | 304 | | | CN | 305 | | | | | 306 | | | |<-Group Info| 307 | | | | Reg | 308 | | | | | 309 | | | |Group Info->| 310 | | | | | 311 | | | |<--Req Msg--| 312 | | | | (group A) | 313 | | | | | 314 | | | Mapping | 315 | | | group | 316 | | | | | 317 | | |<----Req Msg----| | 318 | | | | | 319 | | Authentication of | | 320 | | GA | | 321 | | | | | 322 | |<----Req Msg-----| | | 323 | | | | | 324 | | | | | 325 |<---------Req Msg-------------| | | 326 | | | | | 328 Figure 2 Group Authentication Procedure 330 4. Consideration 332 In this document, we define necessary functions and procedures when 333 corresponding nodes send a request message to group devices. In 334 future work, we will refine and list more use cases requiring the 335 group authentication and define a function, entity, procedure and so 336 on. Moreover, we consider key management and dynamic key registration 337 within the group. 339 5. Security Considerations 341 TBD 343 6. IANA Considerations 345 This document has no IANA actions. 347 7. Conclusion 349 In this document, we described use cases and an efficient way to 350 authenticate an entity for a group communication. Based on the use 351 cases, we will add more functions and procedures. 353 8. References 355 8.1. Normative References 357 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 358 Application Protocol (CoAP)", RFC 7252, June 2014. 360 [I.D.ietf-ace-usecases-04] 362 L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. 363 Kumar, "ACE use cases", draft-ietf-ace-usecases-04, June 04, 364 2015. 366 [I.D.ietf-dice-profile-13] 368 H. Tschofenig, Ed., T. Fossati," A TLS/DTLS Profile for the 369 Internet of Things", draft-ietf-dice-profile-13, June 11, 370 2015. 372 [RFC7228] C. Bormann, M. Ersue, A. Keranen, "Terminology for 373 Constrained-Node Networks", RFC7228, May, 2014. 375 8.2. Informative References 377 9. Acknowledgments 378 Authors' Addresses 380 Hyunsik Yang 381 Soongsil University 382 369, Sangdo-ro, Dongjak-gu, 383 Seoul 156-743, Korea 384 Email: yangun@dcn.ssu.ac.kr 386 Youngki Park 387 Soongsil University 388 369, Sangdo-ro, Dongjak-gu, 389 Seoul 156-743, Korea 390 Email: ykpark@dcn.ssu.ac.kr 392 Namhi Kang 393 HERIT Corporation 394 613, Seolleung-ro, Gangnam-gu, 395 Seoul 135-833, Korea 396 Email: kang@herit.net 397 URI: http://www.herit.net 399 Younghan Kim 400 Soongsil University 401 369, Sangdo-ro, Dongjak-gu, 402 Seoul 156-743, Korea 403 Email: younghak@ssu.ac.kr