idnits 2.17.1 draft-kang-ace-secure-configuration-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 2 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: On receiving the encrypted value from SBS(s), SBR(c) can know the key IK_i thereby calculating PSK. SBR(c) encrypts the concatenation value of RN_i, RN_c and AK_i with the key IK_i. Then it sends both the encrypted value and his ID_c to SBI(i). Note that, SBR(c) MUST not transmit the derived PSK over the public network. -- The document date (October 23, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ACE Working Group Namhi Kang 2 Internet Draft Duksung Women's University 3 Intended status: Informational Jaeduck Choi 4 Expires: April 22, 2015 NSRI 5 Seungwook Jung 6 Souhwan Jung 7 Younghan Kim 8 Soongsil University 9 October 23, 2014 11 Security Key configuration for resource constrained devices 12 draft-kang-ace-secure-configuration-00 14 Abstract 16 This document presents a secure method to configure/reconfigure a key 17 for a resource constrained node when it initially joins to network 18 that is currently in operation. The method is suited for a scenario, 19 where resource constrained nodes are interconnected with each other 20 and thus form a network called Internet of Things. It is assumed that 21 communications for all nodes are based on TCP/IP protocols and the 22 nodes use the constrained application protocol (CoAP). The presented 23 method does not cover all operations of secure bootstrapping for IoT 24 networks, but it is intended to securely support self-reconfiguration 25 of the pre-installed temporary key of joined node. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 22, 2015. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction ................................................ 4 61 2. Terminology ................................................. 5 62 3. System Architecture ......................................... 7 63 4. Process Flow ................................................ 9 64 5. Security Considerations..................................... 11 65 6. IANA Considerations ........................................ 11 66 7. Acknowledgments ............................................ 11 67 8. References ................................................. 12 68 8.1. Normative References................................... 12 69 8.2. Informative References................................. 12 71 1. Introduction 73 A rapidly growing number and various types of devices including smart 74 small things such as sensors and actuators are trying to connect to 75 the Internet as time goes by. This draft presents a simple but 76 efficient approach to reconfigure a security key for resource 77 constrained small things that are often defined as network nodes 78 having 8 bit processing microcontrollers with limited amounts of 79 memory. The network is also constrained one (e.g. 6LoWPAN having high 80 packet error rates and a typical throughput of 10s of kbit/s) 81 [RFC7252]. 83 Pre-shared key (PSK) based secure schemes are well known and widely 84 used for various security services in Internet. All such schemes 85 strictly assume that the PSK is only known to the two communication 86 entities involved in current security service. Consequently, the 87 security of the schemes are compromised if the assumption is broken. 89 However, it is still not clear how PSK of resource constrained node 90 can be initially configured in a secure manner in Internet of things 91 (IoT). Typically, things used for IoT might be manufactured and 92 installed by different subjects (simply person) [SecCons]. That is, 93 in general situation, a system administrator may make orders to 94 several different installers. After that, each of the installers 95 purchases one or more different set of things from one or more 96 different manufacturers. It is also unlikely that a single subject 97 installs all nodes used for a large application domain (e.g. all 98 nodes in huge building). 100 This draft considers a scenario, where nodes are initially configured 101 by an installer (or a manufacturer in some cases) during enrolment 102 phase (or manufacturing/factory configuration phase). If secure 103 credential including PSK is required to be configured in this phase, 104 the trust between installer (or manufacturer) and system 105 administrator is extremely important. However, this is not easy 106 process because manufacturer, installer and service provider do not 107 share a tight and trust relationships in general cases. Even if the 108 case is properly settled, there might be several secure threats and 109 vulnerabilities to be handled. 111 As a conceptual solution, this draft presents an initial setup method 112 that might be a part of secure bootstrapping scheme. The basic idea 113 of the method specified in this document is motivated from a lock of 114 suitcase. Simple and default password such as '0000' or '1234' is 115 initially setup on a lock of suitcase in selling. Owner can change 116 the password after purchasing. In our method, similarly, initial key 117 of a node is configured by installer during bootstrapping phase. When 118 the node join to an existing network, the key (i.e. PSK) can be 119 securely reconfigured. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119] when they appear in ALL CAPS. These words may also appear 127 in this document in lower case as plain English words, absent their 128 normative meanings. 130 This draft uses notations and abbreviations as follows. 132 SBI(i) 134 Shorten abbreviation of a secure bootstrapping initiator i (i.e. 135 new node required to be reconfigured); it is a constrained device 136 having poor input/output interfaces. 138 SBR(c) 140 Shorten abbreviation of a secure bootstrapping respondent c; it 141 is generally regarded as a controller (not highly constrained) of 142 a service domain. 144 SBS(s) 146 Shorten abbreviation of a secure bootstrapping server s; it can 147 be an authenticated register or authentication server. 149 ID_A 151 Denoting 32bits identifier (ID) of entity A. 153 NID_A 155 Denoting network ID used for access to communication entity A; it 156 can be a socket ID (i.e. IPv4 or IPv6 address and port number). 158 RN_A 159 Denoting 128bits integer used for a secure random number 160 generated by entity A; for example, a random number generated by 161 SBI is referred to as RN_i. 163 IK_N 165 Denoting 128bits symmetric key pre-installed by installer or 166 manufacturer for node N; the key is used for a partial 167 transaction of mutual authentication and derivation of PSK (see 168 section 4 in detail). 170 PSK 172 Shorten abbreviation of a 128bits pre-shared key derived from the 173 IK. The PSK is a shared key between a node and authenticated 174 register (or authentication server) in a specific service domain. 176 SK_i 178 Shorten abbreviation of a 128bits session key for i^th session. A 179 PSK can be used to derive session keys for various security 180 protocols designed by service administrator (see [RFC4764] for 181 example). 183 AK_N 185 Denoting 128bits symmetric key generated by authentication server 186 (i.e. SBS(s) in this draft) or system administrator to protect 187 the PSK stored in node N. 189 TS 191 Denoting time stamp of operation; it enables sender (TS 192 generator) to inform timeliness and uniqueness to receiver. 194 SK_cs 196 Denoting a 128bits symmetric key shared between entity c and s. 198 || 200 Notation used to denote concatenation of data. 202 V 204 Notation used to denote a logical operator Exclusive OR. 206 E(M, SK) 208 Denoting a function to encrypt a plain text 'M' by using a 209 symmetric key SK. 211 D(C, SK) 213 Denoting a function to decrypt a cipher text 'C' by using a 214 symmetric key SK. 216 Other security related terminologies used in this document are based 217 on [RFC4949]. 219 3. System Architecture 221 Secure bootstrapping is regarded as a difficult problem in Internet 222 of Things. This is mainly because lots of things connected to 223 Internet are resource constrained. Especially, user-device interfaces 224 they have are not enough for doing configurations manually by person 225 (i.e. inadequate or even no input/output equipment such as display or 226 keyboard). 228 As one of solutions, this document proposes a method which allows a 229 node to reconfigure a symmetric key (i.e. pre-installed key in 230 enrolment phase) automatically upon joining to existing network. 231 After the secure configuration phase, an installer (or manufacturer) 232 cannot read/modify/insert any communication data even though he did 233 initial pre-setup of secure credential of communicating nodes. 235 The following figure illustrates simplified lifecycle of a 236 constrained nodes. 238 |Re-Ownership| |Re-Bootstrap| 240 | | 242 V V 244 |Manufacture| --> |Install| --> |Bootstrapping| --> |Operation| 246 <--- Enrolment Phase ----> <-- Handled by System Admin -> 248 Figure 1. Simplified lifecycle of a constrained nodes 250 The method of this document is based on a straightforward scenario, 251 where resource constrained things such as sensors or actuators are 252 generally designed and manufactured according to their own specific 253 tasks in advance. Also, a pre-defined controller covers and 254 communicates with his associated things according to his roles (or 255 policy) defined in a service domain. For example, a thermostat, which 256 can be a controller, manages and communicates several temperature 257 sensors, humidity sensors, window handle devices, heating controller, 258 air conditioner, and more. 260 This document does not assume that a system administrator trusts an 261 installer (or manufacturer) even though he makes orders for the 262 installer. This is because trust and responsibility of installer, who 263 buys and install devices, are different from those of system 264 administrator. 266 In this scenario, the following transactions MUST be done prior to 267 the secure key reconfiguration (i.e. procedures in enrolment Phase). 269 1. System administrator makes orders and requests initial setup of 270 devices to an installer. Pre-setup information is a set of 271 values that include ID and NID of controller for each of the 272 devices, and a temporary key used as an initial key (i.e. IK_N). 273 Note that, all devices handled by a single installer may share 274 the same IK_N. This concept is similar to the default password 275 for all suitcases manufactured by a single company. 277 2. System administrator also stores the same initial information 278 for each of nodes in authentication server (or authenticated 279 register). The administrator may utilize procedures (e.g. web 280 based registration) managed by manufacturer to get the 281 information. Note that a controller can also perform operations 282 of an authentication server in case of a small network. 284 3. Installer purchases devices and then configures the information 285 requested by the administrator in doing installation phase (a 286 part of enrolment phase). Some of the information for a node 287 may be pre-configured by manufacturer. 289 4. When a node joins to network, it knows NID of its associated 290 controller with which he can communicate. Also, authentication 291 server has lists including node ID and pre-installed key for 292 new nodes. 294 5. PSK reconfiguration phase can be then started. 296 In order to make a practical and efficient method, the proposed 297 method requires only a single cryptographic primitive that is AES 298 with 128bits length of key [AES]. All cryptographic primitives cannot 299 be installed on resource restricted devices, mainly because of 300 limited size of flash or RAM. For this reason, CoAP also does not 301 consider all modes of cryptographic operations in DTLS which is a 302 recommended secure protocol for CoAP applications. In case of 303 establishing a CoAP session using a pre-shared key mod of DTLS, 304 implementation of cipher suite TLS_PSK_WITH_AES_128_CCM_8 specified 305 in [RFC6655] is mandatory. 307 4. Process Flow 309 There are three message exchanges between a new node SBI(i) and 310 network node(s) (i.e. SBR(c) and SBS(s)). A controller SBR(c) may 311 include functions of both SBR(c) and SBS(s) depending on the size of 312 application domain or the ability of SBR (i.e. computing power and 313 memory). Mutual authentication and PSK reconfiguration procedures are 314 shown in Figure 2. 316 ------- ------ ------ 317 SBI(i) SBR(c) SBS(s) 318 ------- ------ ------ 319 | | | 320 | ID_i, RN_i | | 321 | --------------------------->| | 322 | |ID_i, ID_c, RN_i, RN_c, TS, TID | 323 | |------------------------------->| 324 | | | 325 | | | 326 | | E(IK_i||ID_i||TID||AK_i, SK_cs)| 327 | |<-------------------------------| 328 | | | 329 | | | 330 |ID_c,E(RN_i||RN_c||AK_i,IK_i)| | 331 |<--------------------------- | | 332 | | | 333 | | | 334 | E(RN_c, PSK) | | 335 | --------------------------->| | 336 | | | 337 | | | 339 Figure 2. Message Exchange for PSK Reconfiguration 341 When a new node SBI(i) joins an existing network, he generates a 342 random number RN_i and sends it with his identifier ID_i to his 343 controller SBR(c). The NID_of SBR(c) (i.e. IP address and port 344 number) has been pre-configured by installer of the SBI(i) in the 345 enrolment phase as specified in section 3 of this draft. 347 Upon receiving the message, SBR(c) generates a random number RN_c and 348 a sequence number used as a transaction ID (i.e. TID). Then he sends 349 the two values with his ID_c, time stamp (TS) and the message 350 received from SBI(i) to the authentication server SBS(s). TS allows 351 SBR(s) to derive the valid time of key and verify the freshness of 352 the arrived message. Specific period of the expiration of key (i.e. 353 PSK) is out of scope of this document. 355 The authentication server SBS(s) first discovers the IK_i for node 356 ID_i in his secure repository. SBS(s) now can derive a new PSK for 357 the node SBI(i) and replace the IK_i with the PSK, where the PSK for 358 SBI(i) is derived as follows. 360 PSK_i = E(RN_i V RN_c, IK_i) 362 After the reconfiguration of PSK for node SBI(i), SBS(s) generates a 363 AK_i which is a secret key (or password). The AK_i is used for 364 protecting PSK_i to be stored in constrained Node i. All nodes 365 covered by SBS(s) can share a single AK_i or SBS(s) can generate a 366 key for each of the nodes depending on service or security policy. 367 Finally, SBS(s) encrypts the concatenation value of IK_i, ID_i, TID 368 and AK_i with the symmetric key SK_cs which is a shared key between 369 SBS(s) and SBR(c). This is because SBR(c) does not have the key IK_i 370 at this moment. SBS(s) then sends the encrypted value to SBR(c). 372 On receiving the encrypted value from SBS(s), SBR(c) can know the key 373 IK_i thereby calculating PSK. SBR(c) encrypts the concatenation value 374 of RN_i, RN_c and AK_i with the key IK_i. Then it sends both the 375 encrypted value and his ID_c to SBI(i). Note that, SBR(c) MUST not 376 transmit the derived PSK over the public network. 378 SBI(i) can verify the authenticity of SBR(c) by using the decrypted 379 RN_i value from the received message. Finally, SBI(i) can configure 380 his PSK thereafter sending the encryption value of RN_c with the new 381 key PSK to SBR(c) for the authenticity validation. SBI(i) derives a 382 session key SK_i from the PSK and then reconfigures his secure 383 credential as follows. 385 IK_i <-- E(PSK, AK_i) 387 After that, SBI(i) deletes AK_i which is only stored in SBS(s). This 388 is because small device is generally more vulnerable to various 389 physical attacks such as theft and forgery than SBS(s). When a node 390 needs to reconfigure such secure parameters, SBS(s) must send the 391 encrypted AK_i. 393 5. Security Considerations 395 The method of this draft uses a single cryptographic primitive AES 396 [AES] which is used for secure bootstrapping (exactly in the PSK 397 reconfiguration phase). Single cryptographic primitive implementation 398 is rationally suited for the scenario where applications or services 399 require a secure session (confidentiality and integrity of data) in 400 IoT. Because small devices with low computing power and little 401 storage are major entities in IoT. According to a full bootstrapping 402 policy, the PSK can be used for mechanisms of session key derivation 403 and/or entity authentication. 405 As discussed in ESP-PSK [RFC4764], it goes without saying that a 406 single cryptographic primitive may not support extensible security 407 services such as identity protection, perfect forward secrecy and 408 others. However, small devices consisting of Internet of Things might 409 not support all of security services inherently. Service developer 410 should therefore define a scope of his service strictly and consider 411 trade-off between capability and security. 413 Security analysis and evaluation of various aspects of the method 414 remain to be done. 416 6. IANA Considerations 418 This memo includes no request to IANA 420 7. Acknowledgments 422 (TBD) 424 8. References 426 8.1. Normative References 428 [RFC4764] F. Bersani, H. Tschofenig, "The EAP-PSK Protocol: A Pre- 429 Shared Key Extensible Authentication Protocol (EAP) Method", 430 RFC 4764, January 2007. 432 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 433 4949, August 2007. 435 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 436 Transport Layer Security (TLS)", RFC 6655, July 2012. 438 [RFC7252] Shelby, Z., Hartke, K., and Bormann, C., "The Constrained 439 Application Protocol (CoAP)", RFC 7252, June 2014. 441 [SecCons] O. Garcia-Morchon, S. Kumar, S. Keoh, R. Hummen, R. Struik, 442 "Security Considerations in the IP-based Internet of 443 Things", Internet draft (draft-garcia-core-security-06), 444 September 2013. 446 [AES] National Institute of Standards and Technology, "Specification 447 for the Advanced Encryption Standard (AES)", Federal 448 Information Processing Standards (FIPS) 197, November 2001. 450 8.2. Informative References 452 [RFC2119] S. Brander, "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 Author's Addresses 457 Namhi Kang 458 Duksung Women's University 459 Seoul Korea 460 Email: kang@duksung.ac.kr 461 URI: http://www.duksung.ac.kr 463 Jaeduck Choi 464 NSRI (National Security Research Institute) 465 Daejeon, Korea 466 Email: cjduck@ensec.re.kr 468 Seungwook Jung 469 Soongsil University 470 Seoul Korea 471 Email: seungwookj@ssu.ac.kr 473 Souhwan Jung 474 Soongsil University 475 Seoul Korea 476 Email: souhwanj@ssu.ac.kr 478 Younghan Kim 479 Soongsil University 480 Seoul Korea 481 Email: younghak@ssu.ac.kr