idnits 2.17.1 draft-yang-ace-groupauth-01.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 7 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 (October 19, 2015) is 3112 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 125 looks like a reference -- Missing reference section? 'RFC7252' on line 409 looks like a reference -- Missing reference section? 'RFC7228' on line 424 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: April 2016 Soongsil University 5 Namhi Kang 6 HERIT 7 October 19, 2015 9 Authentication architecture for a group of constrained devices 10 draft-yang-ace-groupauth-01.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 April 15, 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 ................. 6 80 2.1.3. Mobile sink for isolated sensor environment........ 6 81 2.1.4. Requirements for mobile sink ...................... 6 82 2.1.5. Smart car ......................................... 6 83 2.1.6. Requirements for smart car ........................ 7 84 3. Group authentication architecture and procedures ............ 7 85 3.1. Architecture ........................................... 7 86 3.2. Group authentication procedure ......................... 8 87 3.2.1. Device registration ............................... 8 88 3.2.2. Resource discovery ................................ 9 89 3.3. Group authentication procedure (inbound) ............... 9 90 4. Consideration .............................................. 10 91 5. Security Considerations .................................... 10 92 6. IANA Considerations ........................................ 11 93 7. Conclusion ................................................. 11 94 8. References ................................................. 11 95 8.1. Normative References................................... 11 96 8.2. Informative References................................. 11 97 9. Acknowledgments ............................................ 11 99 1. Introduction 101 Currently, many constrained devices are used for various applications 102 in various fields; therefore, their authentication issues should be 103 considered carefully. The general authentication method is based on 104 one-by-one communication (i.e. unicast). However, there will be 105 burdens in a scenario, where a node needs to authenticate large 106 number of devices at the same time. Moreover, when a lot of devices 107 are located in one place, it will cause a bottleneck. Furthermore, 108 constrained devices have a limitation in adopting various general 109 cryptography mechanisms since they have limited processing power, 110 storage space and transmission capacities. 112 This document considers various use cases for authentication and 113 authorization in constrained environments and proposes a mechanism 114 and a procedure for group authentication. 116 Based on the use cases, this document also defines a group entity 117 functionality and initiate procedure when operator of each device 118 wants to get mutual authentication. 120 1.1. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC-2119 [RFC2119]. 126 Group 128 Users can make a group based on application usage or authentication 129 method. 131 Group cluster header 133 Group cluster header is one of the group members and is a 134 representative of a specific group. 136 Group agent 138 Group agent can manage several groups and it also has a required 139 function for group authentication. 141 Group ID 143 It is a unique ID that identifies a specific group. 145 Group shared key 147 It is used by the device and group agent to verify each other. 149 2. Use cases 151 Group authentication enables a node to authenticate all devices in a 152 group at once. Group authentication can reduce both computing and 153 signaling cost of the authentication procedure and enhance security 154 of the constrained devices. 156 This section describes use cases that prefer to use a group based 157 authentication rather than one-by-one authentication. Based on the 158 use cases, we list several requirements and considerations. 160 2.1.1. Wearable devices 162 Suppose that Alice has four devices; a heartbeat-monitoring device, a 163 blood pressure-monitoring device, smart glasses for virtual screen, 164 and a smart ring to control the virtual screen. There might be two 165 different groups. A group of devices, which includes the heartbeat- 166 monitoring device and blood pressure-monitoring device, is used for 167 health care of Alice. The other group is used for helping Alice in 168 her workplace. The smart glasses and the ring belong to the second 169 group. 171 When Alice arrives in her workplace, the smart glasses and smart ring 172 may need to get data from a database server or IT management server 173 of the company, and the server may need to update these devices' 174 firmware. Both of the scenarios require mutual authentication since 175 the company servers and Alice's devices must verify each other. In 176 this scenario, the two servers and the two devices are mutually 177 authenticated in a one by one manner (i.e. four different procedures 178 for each of the entity pairs). However, more increasing the number of 179 authentication entity (i.e. either server or device) results in 180 higher burden on the entity. Thus, a group authentication mechanism 181 is required. 183 After Alice leaves the office, Alice goes to a hospital to check her 184 health status. When she arrives at the hospital and meets a doctor, 185 if the doctor wants to change the configuration in a device or get 186 her health data, only the member devices of health care group should 187 be authenticated by using a group authentication mechanism. 189 2.1.2. Requirements for wearable devices 191 Authentication mechanism is required for every device to verify its 192 communication entity in advance of data exchange. The authentication 193 mechanism would be changed according to device capability. 195 Group key should be shared to verify identities between devices and 196 group agent. 198 The discovery procedure between group agent and corresponding nodes 199 is out of scope. 201 2.1.3. Mobile sink for isolated sensor environment 203 In Wireless Sensor Network, Mobile sink, which has a function 204 allowing nodes to move anywhere, is to be a solution for aggregating 205 data. Especially, mobile sink is used for gathering sensor data from 206 deployed sensors, where they are located in isolated environment such 207 as the heart of a mountain or the deep sea. Based on sensor 208 characteristics, user can make a group such as a humidity group or a 209 temperature group and others. In some scenarios, authentication is 210 required for secure communication between mobile sink and sensor node. 211 For that, a mobile sink can authenticate its corresponding group 212 cluster header based on the group authentication mechanism. 214 2.1.4. Requirements for mobile sink 216 Group key should be shared to verify identities between sensor and 217 mobile sink. 219 Based on group information, mobile sink can request message to group 220 cluster header. 222 The discovery procedure between group agent and corresponding nodes 223 is not necessary. 225 2.1.5. Smart car 227 Alice and Bob have a smart car which may have lots of sensors for 228 managing tire air pressure, engine oil, break oil, headlight, battery, 229 etc. When they sit on the car seat, the car detects its user and 230 sends status information of car to them; thereby they can check 231 condition of car easily. Based on the car's information, they can 232 examine the car and prevent accident occurred by car's problem. 233 Moreover, there might be several actuators in the car for 234 automatically adjusting car seats, room mirror, side view mirror, etc. 235 So, after checking the car's status, actuators send request message 236 to driver to get driver's identity. Based on the drivers identity, 237 every actuators set adjustment value which are modified by driver's 238 characteristic. 240 2.1.6. Requirements for smart car 242 Authentication mechanism is required for every sensors or actuators 243 to verify its communication entity in advance of data exchange. The 244 authentication mechanism would be changed according to device 245 capability. 247 Group key should be shared to verify identities between sensor and 248 group agent (e.g. driver's smart phone). 250 When a device (i.e. sensor or actuator) is replaced, new device 251 should be securely registered to its corresponding group agent. 253 When group member are changed, group key should be securely changed 254 and distributed to all group members. 256 If the group cluster header will leave, group cluster header will be 257 re-selected from the group members. 259 Group agent has information about group mapping table between device 260 and CN. 262 3. Group authentication architecture and procedures 264 3.1. Architecture 266 As shown in figure 1, the proposed group authentication architecture 267 is hierarchically constructed. Users (application user or service 268 provider) make one or more groups based on application policy or 269 service goal. For example, there might be a group of devices for 270 healthcare service and a group of devices for working, etc. The group 271 agent manages the groups. Also, in a group, one device can be 272 selected as a group cluster header which delegates authentication for 273 other devices in his group. We note here that a device can belong to 274 one or multiple groups (see the device 2 in figure 1). Group agent 275 has a management function and it communicates with its corresponding 276 nodes. In the figure 1, CN indicates a corresponding node. 278 ************************************************ 279 * +-------+ * 280 * +device1+ +----------------------+ * 281 * +-------+ + device 2 + * 282 * +(group cluster header)+--*-----+ 283 * +----------------------+ * | 284 * ############## * | 285 * # # * | 286 * # +-------+ # ****************************+-----------+ +--+ 287 * # +device2+ * +group agent+<-->|CN| 288 * # +-------+ * ########################## +-----------+ +--+ 289 * # * # | 290 ***************** # | 291 # +--------------------+ # | 292 # +-------+ +group cluster header+--#-------+ 293 # +device3+ +--------------------+ # 294 # +-------+ # 295 ########################################### 297 Figure 1 Group Authentication Architecture 299 3.2. Group authentication procedure 301 In this document, we just consider on the inbound case as an initial 302 version of this draft. That is, we define a procedure when a 303 corresponding node (CN) sends a request to a group of devices. Our 304 procedure is divided into two phases. The first phase is the device 305 registration with group agent; the second phase is the group 306 authentication. 308 3.2.1. Device registration 310 As discussed in the former section, we assume that groups are made by 311 users, and each group has a header that is the representative device 312 of the group. The header device can be pre-configured by users or can 313 be selected in a dynamic fashion. The way to dynamically decide a 314 header device is out of scope of the current document. When a group 315 header is decided, the header device and its corresponding group 316 agent share a secret key each other. Also, each group header forwards 317 the secret key to its group devices through a secure channel. 319 Alternatively, a group agent performs authentication procedures with 320 a representative header of a group of devices. The authentication 321 between the group agent and the header device can be done by a 322 general asymmetric key based method (i.e. RawPublic Key or 323 Certificate based mode of CoAP over DTLS binding). 325 3.2.2. Resource discovery 327 Corresponding nodes should know their group information to send group 328 based request message to the group agent. Therefore, we should define 329 procedure of gathering group information based on CoAP[RFC7252]. When 330 a corresponding node sends group information request messages to the 331 group agent like a resource discovery message in CoAP, the group 332 agent replies to the corresponding node with group information. 334 3.3. Group authentication procedure (inbound) 336 The general procedure of message flows from corresponding nodes to 337 devices is described below. A corresponding node sends the 338 authentication request message to its group agents. After receiving 339 the authentication request message, the group agent verifies the 340 corresponding node identity. After authentication, the corresponding 341 node sends the group discovery message to the group agent. 342 Corresponding nodes that need group information from the group agent 343 sends a request message (information, configuration) to the group 344 agent with the group ID. When a group agent receives the request 345 message, it looks up group ID information and forwards it to the 346 group cluster header that corresponds to the received group ID. The 347 group cluster header verifies the group agent identity and sends a 348 request message to devices in its group. 350 Device1(A) Device2(A) Group Cluster Group Agent CN 351 (GCH) (A group) 352 | | | | | 353 | | | |<-Auth Req--| 354 | | | | | 355 | | | Authentication of | 356 | | | CN | 357 | | | | | 358 | | | |<-Group Info| 359 | | | | Reg | 360 | | | | | 361 | | | |Group Info->| 362 | | | | | 363 | | | |<--Req Msg--| 364 | | | | (group A) | 365 | | | | | 366 | | | Mapping | 367 | | | group | 368 | | | | | 369 | | |<----Req Msg----| | 370 | | | | | 371 | | Authentication of | | 372 | | GA | | 373 | | | | | 374 | |<----Req Msg-----| | | 375 | | | | | 376 | | | | | 377 |<---------Req Msg-------------| | | 378 | | | | | 380 Figure 2 Group Authentication Procedure 382 4. Consideration 384 In this document, we define necessary functions and procedures when 385 corresponding nodes send a request message to group devices. In 386 future work, we will refine and list more use cases requiring the 387 group authentication and define a function, entity, procedure and so 388 on. Moreover, we consider key management and dynamic key registration 389 within the group. 391 5. Security Considerations 393 TBD 395 6. IANA Considerations 397 This document has no IANA actions. 399 7. Conclusion 401 In this document, we described use cases and an efficient way to 402 authenticate an entity for a group communication. Based on the use 403 cases, we will add more functions and procedures. 405 8. References 407 8.1. Normative References 409 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 410 Application Protocol (CoAP)", RFC 7252, June 2014. 412 [I.D.ietf-ace-usecases-04] 414 L. Seitz, Ed., S. Gerdes, Ed., G. Selander, M. Mani, S. 415 Kumar, "ACE use cases", draft-ietf-ace-usecases-04, June 04, 416 2015. 418 [I.D.ietf-dice-profile-13] 420 H. Tschofenig, Ed., T. Fossati," A TLS/DTLS Profile for the 421 Internet of Things", draft-ietf-dice-profile-13, June 11, 422 2015. 424 [RFC7228] C. Bormann, M. Ersue, A. Keranen, "Terminology for 425 Constrained-Node Networks", RFC7228, May, 2014. 427 8.2. Informative References 429 9. Acknowledgments 430 Authors' Addresses 432 Hyunsik Yang 433 Soongsil University 434 369, Sangdo-ro, Dongjak-gu, 435 Seoul 156-743, Korea 436 Email: yangun@dcn.ssu.ac.kr 438 Youngki Park 439 Soongsil University 440 369, Sangdo-ro, Dongjak-gu, 441 Seoul 156-743, Korea 442 Email: ykpark@dcn.ssu.ac.kr 444 Namhi Kang 445 HERIT Corporation 446 613, Seolleung-ro, Gangnam-gu, 447 Seoul 135-833, Korea 448 Email: kang@herit.net 449 URI: http://www.herit.net 451 Younghan Kim 452 Soongsil University 453 369, Sangdo-ro, Dongjak-gu, 454 Seoul 156-743, Korea 455 Email: younghak@ssu.ac.kr