idnits 2.17.1 draft-kang-core-secure-reconfiguration-01.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 -- The document date (February 11, 2014) is 3699 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 4764 ** Downref: Normative reference to an Informational RFC: RFC 4949 ** Downref: Normative reference to an Informational draft: draft-garcia-core-security (ref. 'SecCons') -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE Working Group Namhi Kang 2 Internet Draft Duksung Women's University 3 Intended status: Standard Track Seung-Hun Oh 4 Expires: August 11, 2014 Shimkwon Yoon 5 ETRI 6 February 11, 2014 8 Secure initial-key reconfiguration for resource constrained devices 9 draft-kang-core-secure-reconfiguration-01 11 Abstract 13 This document presents a secure method to configure a key for a 14 resource constrained node when it initially joins to network that is 15 currently in operation. The method is suited for a scenario, where 16 resource constrained nodes are interconnected with each other and 17 thus form a network called Internet of Things. It is assumed that 18 communications for all nodes are based on TCP/IP protocols and the 19 nodes use the constrained application protocol (CoAP). The presented 20 method does not cover all operations of secure bootstrapping for IoT 21 networks, but it is intended to securely support self-reconfiguration 22 of the pre-installed temporary key of joined node. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 11, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction ................................................ 4 59 2. Terminology ................................................. 5 60 3. System Architecture ......................................... 7 61 4. Process Flow ................................................ 8 62 5. Security Considerations .................................... 10 63 6. IANA Considerations ........................................ 10 64 7. Acknowledgments ............................................ 11 65 8. References ................................................. 11 66 8.1. Normative References................................... 11 67 8.2. Informative References................................. 11 69 1. Introduction 71 A rapidly growing number and various types of devices including smart 72 small things such as sensors and actuators are trying to connect with 73 Internet as time goes by. This draft presents a simple but efficient 74 approach to reconfigure a secure key for resource constrained small 75 things that are often defined as network nodes having 8 bit 76 processing microcontrollers with limited amounts of memory. The 77 network is also constrained one (e.g. 6LoWPAN having high packet 78 error rates and a typical throughput of 10s of kbit/s) [CoAP]. 80 Pre-shared key (PSK) based secure schemes are well known and 81 frequently used for various security services in Internet. All such 82 schemes strictly assume that the PSK is only known to two entities 83 involved in current security service. Consequently, the security of 84 the schemes are compromised if the assumption is broken. 86 However, it is still not clear how PSK of resource constrained node 87 can be initially configured in a secure manner in Internet of things 88 (IoT). Typically, things used for IoT might be manufactured and 89 installed by different subjects (simply person) [SecCons]. That is, 90 in general situation, a system administrator may make orders to 91 several different installers. After that, each of the installers 92 purchases one or more different set of things from one or more 93 different manufacturers. It is also unlikely that a single subject 94 installs all nodes used for a large application domain (e.g. all 95 nodes in huge building). 97 This draft considers a scenario, where nodes are initially configured 98 by an installer (or a manufacturer in some cases) during 99 bootstrapping phase (or manufacturing/factory configuration phase). 100 If secure credential including PSK is required to be configured in 101 this phase, the trust between installer (or manufacturer) and system 102 administrator is extremely important. However, this is not easy 103 process because manufacturer, installer and service provider do not 104 share a tight and trust relationships in general cases. Even if the 105 case is properly settled, there might be several secure threats and 106 vulnerabilities to be handled. 108 As a conceptual solution, this draft presents an initial setup method 109 that might be a part of secure bootstrapping scheme. The basic idea 110 of the method specified in this document is motivated from a lock of 111 suitcase. Simple and default password such as '0000' or '1234' is 112 initially setup on a lock of suitcase in selling. Owner can change 113 the password after purchasing. In our method, similarly, initial key 114 of a node is configured by installer during bootstrapping phase. When 115 the node join to an existing network, the key (i.e. PSK) can be 116 securely reconfigured. 118 2. Terminology 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in 123 [RFC2119] when they appear in ALL CAPS. These words may also appear 124 in this document in lower case as plain English words, absent their 125 normative meanings. 127 This draft uses notations and abbreviations as follows. 129 SBI(i) 131 Shorten abbreviation of a secure bootstrapping initiator i (i.e. 132 new node required to be reconfigured); it is a constrained device 133 having poor input/output interfaces. 135 SBR(c) 137 Shorten abbreviation of a secure bootstrapping respondent c; it 138 is generally regarded as a controller (not highly constrained) of 139 a service domain. 141 SBS(s) 143 Shorten abbreviation of a secure bootstrapping server s; it can 144 be an authenticated register or authentication server. 146 ID_A 148 Denoting 32bits identifier (ID) of entity A. 150 NID_A 152 Denoting network ID used for access to communication entity A; it 153 can be a socket ID (i.e. IPv4 or IPv6 address and port number). 155 RN_A 156 Denoting 128bits integer used for a secure random number 157 generated by entity A; for example, a random number generated by 158 SBI is referred to as RN_i. 160 IK_N 162 Denoting 128bits symmetric key pre-installed by installer or 163 manufacturer for node N; the key is used for a partial 164 transaction of mutual authentication and derivation of PSK (see 165 section 4 in detail). 167 PSK 169 Shorten abbreviation of a 128bits pre-shared key derived from the 170 IK. The PSK is a shared key between a node and authenticated 171 register (or authentication server) in a specific service domain. 172 A PSK can be used to derive session keys for various security 173 protocols designed by service administrator (see [RFC4764] for 174 example). 176 TS 178 Denoting time stamp of operation; it enables sender (TS 179 generator) to inform timeliness and uniqueness to receiver. 181 SK_cs 183 Denoting a 128bits symmetric key shared between entity c and s. 185 || 187 Notation used to denote concatenation of data. 189 V 191 Notation used to denote a logical operator Exclusive OR. 193 E(M, SK) 195 Denoting a function to encrypt a plain text 'M' by using a 196 symmetric key SK. 198 D(C, SK) 200 Denoting a function to decrypt a cipher text 'C' by using a 201 symmetric key SK. 203 Other security related terminologies used in this document are based 204 on [RFC4949]. 206 3. System Architecture 208 Secure bootstrapping is regarded as a difficult problem in Internet 209 of Things. This is mainly because lots of things connected to 210 Internet are resource constrained. Especially, user-device interfaces 211 they have are not enough for doing configurations manually by person 212 (i.e. inadequate or even no input/output equipment such as display or 213 keyboard). 215 As one of solutions, this document proposes a method which allows a 216 node to reconfigure a symmetric key (i.e. PSK) automatically upon 217 joining to existing network. After the reconfiguration phase, an 218 installer (or manufacturer) cannot read/modify/insert any 219 communication data even though he did initial pre-setup of secure 220 credential of communicating nodes. 222 The method of this document is based on a straightforward scenario, 223 where resource constrained things such as sensors or actuators are 224 generally designed and manufactured according to their own specific 225 tasks in advance. Also, a pre-defined controller covers and 226 communicates with his associated things according to his rolls 227 defined in a service domain. For example, a thermostat, which is a 228 controller, manages and communicates several temperature sensors, 229 humidity sensors, window handle devices, heating controller, air 230 conditioner, and more. 232 This document does not assume that a system administrator trusts an 233 installer even though he makes orders for the installer. This is 234 because trust and responsibility of installer, who buys and install 235 devices, are different from those of system administrator. 237 In this scenario, the following transactions MUST be done prior to 238 the secure key reconfiguration. 240 1. System administrator makes orders and requests initial setup of 241 devices to an installer. Pre-setup information is a set of 242 values that include ID and NID of controller for each of the 243 devices, and a temporary key used as an initial key (i.e. IK_N). 244 Note that, all devices handled by a single installer can share 245 the same IK_N. This concept is similar to the default password 246 for all suitcases manufactured by a single company. 248 2. System administrator also stores the same initial information 249 for each of nodes in authentication server (or authenticated 250 register). Note that a controller can also perform operations 251 of an authentication server in case of a small network. 253 3. Installer purchases devices and then configures the information 254 requested by the administrator in doing installation phase. 255 Some of the information for a node may be pre-configured by 256 manufacturer. 258 4. When a node joins to network, it knows NID of his associated 259 controller with which he can communicate. Also, authentication 260 server has lists of IDs for new nodes. 262 5. PSK reconfiguration phase is then started. 264 In order to make a practical and reasonable method, the proposed 265 method requires only a single cryptographic primitive that is AES 266 with 128bits length of key [AES]. All cryptographic primitives cannot 267 be installed on resource restricted devices, mainly because of 268 limited size of flash or RAM. For this reason, CoAP also does not 269 consider all modes of cryptographic operations in DTLS which is a 270 regarded secure protocol for CoAP applications. In case of 271 establishing a CoAP session using a pre-shared key mod of DTLS, 272 implementation of cipher suite TLS_PSK_WITH_AES_128_CCM_8 specified 273 in [RFC6655] is mandatory. 275 4. Process Flow 277 There are three message exchanges between new node SBI(i) and network 278 node(s) (i.e. SBR(c) and SBS(s)). A controller SBR(c) may include 279 functions of both SBR(c) and SBS(s) depending on the size of 280 application domain or the ability of SBR (i.e. computing power and 281 memory). 283 Mutual authentication and PSK reconfiguration procedures are shown in 284 Figure 1. 286 ------- ------ ------ 287 SBI(i) SBR(c) SBS(s) 288 ------- ------ ------ 289 | | | 290 | ID_i, RN_i | | 291 | -------------------------->| | 292 | |ID_i, ID_c, RN_i, RN_c, TS, TID | 293 | |------------------------------->| 294 | | | 295 | | | 296 | | E(IK_i || ID_i || TID, SK_cs) | 297 | |<-------------------------------| 298 | | | 299 | | | 300 | ID_c, E(RN_i || RN_c, IK_i)| | 301 |<---------------------------| | 302 | | | 303 | | | 304 | E(RN_c, PSK) | | 305 | -------------------------->| | 306 | | | 307 | | | 309 Figure 1 Message Exchange for PSK Reconfiguration 311 When a new node SBI(i) joins an existing network, he generates a 312 random number RN_i and sends it with his identifier ID_i to his 313 controller SBR(c). NID_SBR(c) has been pre-configured by installer of 314 the SBI(i) at the initial setup phase as specified in section 3 of 315 this draft. 317 Upon receiving the message, SBR(c) generates a random number RN_c and 318 a serial number used as a transaction ID (i.e. TID). Then he sends 319 the two values with his ID_c, time stamp (TS) and the message 320 received from SBI(i) to the authentication server SBS(s). TS allows 321 SBR(s) to derive the valid time of key and verify the freshness of 322 the arrived message. Specific period of the expiration of key (i.e. 323 PSK) does not covered in this document. 325 The authentication server SBS(s) first discovers the IK_i for node 326 ID_i in his secure repository. SBS(s) now can derive a new PSK for 327 the node SBI(i) and replace the IK_i with the PSK, where the PSK for 328 SBI(i) is derived as follows. 330 PSK_i = E(RN_i V RN_c, IK_i) 332 After reconfiguration of the PSK for node SBI(i), SBS(s) encrypts the 333 concatenation value of IK_i, ID_i and TID with the symmetric key 334 SK_cs which is a shared key between SBS(s) and SBR(c). This is 335 because SBR(c) does not have the key IK_i at this moment. SBS(s) then 336 sends the encrypted value to SBR(c). 338 On receiving the encrypted value from SBS(s), SBR(c) can know the key 339 IK_i thereby calculating PSK. SBR(c) encrypts the concatenation value 340 of RN_i and RN_c with key IK_i. Then it sends the encryption value 341 and his ID_c to SBI(i). Note that, SBR(c) does not transmit PSK over 342 the network. 344 SBI(i) can verify the SBR(c) by using the decrypted RN_i value from 345 the received message. Finally, SBI(i) can reconfigure his PSK 346 thereafter sending the encryption value of RN_c with the new key PSK 347 to SBR(c) for authenticity validation. 349 5. Security Considerations 351 The method of this draft uses a single cryptographic primitive AES 352 [AES] which is used for secure bootstrapping (exactly in the PSK 353 reconfiguration phase). Single cryptographic primitive implementation 354 is rationally suited for the scenario where applications or services 355 require a secure session (confidentiality of data) in IoT. Because 356 small devices with low computing power and little storage are major 357 entities. According to a full bootstrapping policy, the PSK can be 358 used for mechanisms of session key derivation and/or entity 359 authentication. 361 As discussed in ESP-PSK [RFC4764], it goes without saying that a 362 single cryptographic primitive may not support extensible security 363 services such as identity protection, perfect forward secrecy and 364 others. However, small devices consisting of Internet of Things might 365 not support all of security services inherently. Service developer 366 should therefore define a scope of his service strictly and consider 367 trade-off between capability and security. 369 Security analysis and evaluation of various aspects of the method 370 remain to be done. 372 6. IANA Considerations 374 This memo includes no request to IANA 376 7. Acknowledgments 378 (TBD) 380 8. References 382 8.1. Normative References 384 [RFC4764] F. Bersani, H. Tschofenig, "The EAP-PSK Protocol: A Pre- 385 Shared Key Extensible Authentication Protocol (EAP) Method", 386 RFC 4764, January 2007. 388 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 389 4949, August 2007. 391 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 392 Transport Layer Security (TLS)", RFC 6655, July 2012. 394 [CoAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 395 "Constrained Application Protocol (CoAP)", draft-ietf-core- 396 coap-18 (work in progress), June 2013. 398 [SecCons] O. Garcia-Morchon, S. Kumar, S. Keoh, R. Hummen, R. Struik, 399 "Security Considerations in the IP-based Internet of 400 Things", Internet draft (draft-garcia-core-security-06), 401 September 2013. 403 [AES] National Institute of Standards and Technology, "Specification 404 for the Advanced Encryption Standard (AES)", Federal 405 Information Processing Standards (FIPS) 197, November 2001. 407 8.2. Informative References 409 [RFC2119] S. Brander, "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 Author's Addresses 414 Namhi Kang 415 Duksung Women's University 416 Seoul Korea 417 Email: kang@duksung.ac.kr 418 URI: http://www.duksung.ac.kr 420 Seung-Hun Oh 421 ETRI 422 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 423 Korea 424 Phone: +82-62-970-6655 425 Email: osh93@etri.re.kr 427 Shimkwon Yoon 428 ETRI 429 1000-6 Oryong-dong, Buk-gu, Gwangju, 500-480, 430 Korea 431 Phone: +82-62-970-6655 432 Email: skyoon@etri.re.kr