idnits 2.17.1 draft-choi-dice-finegrained-dtls-security-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3467 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) == Missing Reference: 'RFC 5487' is mentioned on line 128, but not defined == Missing Reference: 'RFC 6347' is mentioned on line 353, but not defined ** Obsolete undefined reference: RFC 6347 (Obsoleted by RFC 9147) == Unused Reference: 'RFC7252' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC6347' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC5487' is defined on line 378, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4347 (ref. 'RFC6347') (Obsoleted by RFC 6347) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DICE Working Group Jaeduck Choi 2 Internet Draft Gunhee Lee 3 Intended status: Standards Track NSRI 4 Expires: April 26, 2015 Namhi Kang 5 Duksung Women's University 6 Seungwook Jung 7 Souhwan Jung 8 Soongsil University 9 October 27, 2014 11 Fine-grained Support of Security Services 12 for Constrained Devices using DTLS 13 draft-choi-dice-finegrained-dtls-security-00.txt 15 Abstract 17 This document proposes a method that can selectively apply 18 application data encryption to the DTLS record layer. The CoAP used 19 for resource-constrained devices defines the use of DTLS as a basic 20 security mechanism, and CoAP standard specifies the use of AES_CCM 21 that provides data integrity and confidentiality as a cipher suite 22 for DTLS. However, not all CoAP messages require both data integrity 23 and confidentiality. For example, in case of CoAP messages that 24 include information for turning a light off at home or in a building, 25 or simple ACK information, encryption might not be necessary because 26 such information might not be useful to attackers. Furthermore, from 27 the perspective of effective resource use of resource-constrained 28 devices, reducing the computation load required to perform data 29 encryption every time is necessary. This document describes the 30 methods for CoAP nodes to establish DTLS security channels using the 31 AES_CCM cipher suite, and to selectively apply the encryption 32 function in the DTLS record layer by considering sensitivity to 33 application data leakage 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF), its areas, and its working groups. Note that 42 other groups may also distribute working documents as Internet- 43 Drafts. 45 Internet-Drafts are draft documents valid for a maximum of six 46 months and may be updated, replaced, or obsoleted by other documents 47 at any time. It is inappropriate to use Internet-Drafts as 48 reference 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 25, 2016. 58 Copyright Notice 60 Copyright (c) 2014 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 67 carefully, as they describe your rights and restrictions with 68 respect to this document. Code Components extracted from this 69 document must include Simplified BSD License text as described in 70 Section 4.e of the Trust Legal Provisions and are provided without 71 warranty as described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction ................................................... 3 76 2. Terminology .................................................... 4 77 3. Overview ....................................................... 4 78 4. Protocol Operations ............................................ 7 79 4.1. DTLS Record Layer Header .................................. 7 80 4.2. Node Behaviors ............................................ 8 81 4.2.1. Sender ............................................... 8 82 4.2.2. Receiver ............................................. 9 83 5. Security Considerations ........................................ 9 84 6. IANA Considerations ............................................ 9 85 7. References .................................................... 10 86 7.1. Normative References ..................................... 10 87 7.2. Informative References ................................... 10 88 8. Acknowledgments ............................................... 10 90 1. Introduction 92 IETF CoRE WG has standardized Constrained Application Protocol 93 (CoAP), which can be used for resource-constrained devices [RFC 94 7252]. CoAP defines the use of Datagram Transport Layer Security 95 (DTLS) for device authentication and communication data security, 96 and DTLS specifies TLS_PSK_WITH_AES_128_CCM_8 as a mandatory cipher 97 suite. For a public key-based DTLS cipher suite, CoAP recommends 98 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. The DTLS cipher suite is 99 negotiated between the CoAP client and server in the process of 100 performing the DTLS handshake protocol. For CoAP application data, 101 data integrity and confidentiality are provided in the DTLS record 102 layer protocol by AES_CCM after completing the DTLS handshake 103 protocol. 105 However, examining whether data integrity and confidentiality should 106 be provided always for CoAP messages in resource-constrained devices 107 is necessary. For example, the necessity of a data confidentiality 108 function to send a CoAP message for turning a light switch off in a 109 building or house is questionable. In the case of simultaneously 110 turning on or off all lights in a building or house, such a function 111 can provide clues for identifying whether residents are present in 112 the building or house to malicious attackers intent on illegal entry. 113 However, eavesdropping on CoAP messages for turning off or on some 114 of the lights might not be significant to malicious attackers. In 115 addition, simple ACK messages received from many devices in a CoAP 116 group communication might not be useful to attackers. 117 Furthermore, from the perspective of effective resource use of 118 resource-constrained devices, reducing the computation load 119 required to execute data encryption every time is necessary. 120 Therefore, to minimize resource consumption of IoT devices, 121 selectively applying the data confidentiality function by 122 considering the sensitivity to leakage of application data is 123 necessary. 125 The strain on memory capacity for loading an encryption module on 126 IoT devices should also be considered. TLS defines the cipher suites 127 that provide data integrity only using hash functions such as 128 TLS_PSK_WITH_NULL_SHA256 [RFC 5487]. Only integrity function can be 129 provided to CoAP messages in the DTLS record layer after completing 130 the DTLS handshake protocol with TLS_PSK_WITH_NULL_SHA256. However, 131 if TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_NULL_SHA256 are 132 implemented on resource-constrained devices, burden on memory 133 capacity can occur compared to devices that have only implemented 134 TLS_PSK_WITH_AES_128_CCM_8 because the SHA256 module also has to be 135 loaded. 137 In selectively applying the confidentiality function of CoAP 138 messages, DTLS sessions would be re-established frequently. For 139 example, to send a CoAP message that needs encryption, CoAP nodes 140 will establish the DTLS session to the TLS_PSK_WITH_AES_128_CCM_8 or 141 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suits. While the DTLS 142 session is maintained during the effective period, if a CoAP message 143 that does not require encryption has to be sent, the CoAP nodes will 144 terminate the current DTLS session and resume the DTLS session with 145 the TLS_PSK_WITH_NULL_SHA256 cipher suite. In other words, because 146 of unpredictable IoT service scenario characteristics (the 147 characteristics where sensitivities to data leakage are different), 148 situations can occur often whereby CoAP nodes have to re-establish 149 DTLS sessions for different cipher suites that provide functions for 150 both data integrity and confidentiality, and functions for data 151 integrity only. This becomes a major cause for wasting resources 152 when applying DTLS to CoAP nodes. 154 This document describes a method for selectively applying encryption 155 functions in the DTLS record layer by considering the sensitivity to 156 leakage of application data without changing the DTLS cipher suite, 157 which is defined as the default in the CoAP protocol. 159 2. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 3. Overview 167 This section describes a basic concept of the proposed method. 169 When security negotiation is performed with the default cipher suite 170 during the DTLS handshake protocol between a CoAP client and server, 171 the two nodes complete the preparation for providing the CoAP 172 message data integrity in the DTLS record layer, or for providing 173 both data integrity and confidentiality. Here, how should the CoAP 174 message that needs to provide the data integrity function only in 175 the DTLS record be defined? This question is not covered in the 176 scope of this standard. An example of the solution of the question 177 is the CoAP message that has to provide the integrity function only, 178 and which can be set in advance in the IoT service definition and 179 development stages. Furthermore, such CoAP messages can be 180 identified in the DTLS record layer using a bit flag value or 181 optional field that is defined separately in the existing CoAP 182 header. 184 In the case of CoAP messages that do not require encryption, the 185 CoAP node generates an authentication tag value of the CoAP message 186 in the DTLS record layer, and sends the CoAP message to the 187 corresponding CoAP node without performing encryption (only the 188 process shown in Fig. 1(a) is performed). For CoAP messages that 189 require encryption, an authentication tag value is generated in the 190 DTLS record layer, and both the CoAP message and authentication tag 191 value are encrypted (the processes shown in Figs. 1(a) and 1(b) are 192 performed) and sent. Here, the sender node of the CoAP message sets 193 the encryption flag value of the DTLS record protocol header to "0" 194 (integrity is provided) or "1" (integrity and confidentiality are 195 provided); depending on the flag value, the receiver node of the 196 CoAP message performs the process of integrity verification only or 197 the processes of decryption and integrity verification. Fig. 2 shows 198 the overall flow of the proposed method. 200 +-------+---------------------+-----------------------------------+ 201 | Nonce | Associated data | Plaintext | 202 +-------+---------------------+-----------------------------------+ 203 | 204 V 205 +------+------+------+ +------+ 206 | B_0 | B_1 | B_2 | . . . | B_r | 207 +------+------|------+ +------+ 208 | 209 V 210 +--------+ 211 K ---> | CMAC | 212 +--------+ 213 | 214 V 215 +------+ 216 | Tag | 217 +------+ 219 (a) Authentication 221 +------------------------------------------------+ +------+ 222 | Plaintext | |Ctr_0 | 223 +------------------------------------------------+ +------+ 224 | | 225 | V 226 | +---------+ 227 | K --> | Encrypt | 228 | +---------+ 229 V | 230 +--------+ V 231 Ctr_1, ..., Ctr_m -->| CTR | +-----------+ 232 K -->| | K --> | MSB(Tlen) | 233 +--------+ +-----------+ 234 | | 235 | +------+ V 236 | | Tag | --> XOR 237 | +------+ | 238 V V 239 +------------------------------------------------+ +------+ 240 | | | | 241 +------------------------------------------------+ +------+ 242 | | 243 +-------------------------Ciphertext--------------------------+ 245 (b) Encryption 246 Figure 1: AES_CCM Block Diagram 248 CoAP Client CoAP Server 249 | | 250 | | 251 | <========== DTLS Handshake Protocol ===========> | 252 | with TLS_PSK_WITH_AES_CCM_8 | 253 | | 254 | DTLS Record Protocol | 255 +---|------------------------------------------------------|---+ 256 | | | | 257 | | | | 258 | | Encryption_Flag = 0 (Msg Auth.) | | 259 | |<---------------------------------------------------->| | 260 | | | | 261 | | | | 262 | // // | 263 | | | | 264 | | Encryption_Flag = 1 (Msg. Enc. & Auth.) | | 265 | |<---------------------------------------------------->| | 266 | | | | 267 | | | | 268 +---|------------------------------------------------------|---+ 269 | | 271 Figure 2: Protocol Flow 273 4. Protocol Operations 275 4.1. DTLS Record Layer Header 277 This document defines the encryption flag (F) in the DTLS record 278 layer header to identify whether integrity only or both integrity 279 and confidentiality functions are supported for the messages 280 exchanged between the CoAP nodes through the DTLS security channel. 281 In this document, the top level one bit of the "epoch" field in the 282 DTLS record header is used as a bit to identify whether to apply the 283 encryption. Figure 3 shows the DTLS record layer header format 284 defined in this document, and Table 1 lists the definition of the 285 encryption flag. 287 +-----------------------------------------------------------------+ 288 | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | 289 +-----------------------------------------------------------------+ 290 | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | 291 | Type | Ma | Mi | | number | | (Enc) |(Enc)| 292 +---------+---------+--------+--------+--------+------------+-----+ 293 | | 294 | | 295 +--------+ 296 | 297 V 298 0 1 299 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |F| epoch | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 3: The encryption flag (F) in the DTLS record layer header 306 +----------+------------------------------------------------------+ 307 | F | Description | 308 +----------+------------------------------------------------------+ 309 | 0 | integrity support | 310 +----------+------------+-----------------------------------------+ 311 | 1 | both integrity & encryption support | 312 +----------+------------------------------------------------------+ 314 Table 1: Encryption flag (F) description 316 4.2. Node Behaviors 318 4.2.1. Sender 320 A sender that sends a CoAP message MUST check whether the 321 confidentiality function of the CoAP message is to be provided (not 322 in the scope of this standard document). 324 When only the integrity function has to be provided for the CoAP 325 message, the process of generating an authentication tag value of 326 the CoAP message MUST be performed using the traditional AES_CCM 327 procedure in the DTLS record layer, and the encryption function MUST 328 NOT be performed. The sender MUST set the flag "F" of the DTLS 329 record layer header to "0." Then, the sender MUST send the CoAP 330 message and authentication tag value to the CoAP receiver. 332 When both the integrity and confidentiality functions have to be 333 provided for the CoAP message, according to the AES_CCM procedure, 334 the CoAP message authentication tag value MUST be generated and the 335 message MUST be encrypted in the DTLS record layer. Prior to sending 336 the encrypted message, CoAP MUST set the flag "F" of the DTLS record 337 layer header to "1." The sender then MUST send the encrypted CoAP 338 message to the CoAP receiver. 340 The other processes managed in the DTLS record layer MUST follow the 341 DTLS 1.2 [RFC 6347] standard. 343 4.2.2. Receiver 345 The receiver node that receives the CoAP message through the DTLS 346 security channel MUST check the value of the flag "F" in the DTLS 347 record layer header. If the flag value is "0," only the 348 authentication tag value of the CoAP message MUST be verified; if 349 the flag value is "1," the processes to decrypt the CoAP message and 350 verify the authentication tag value MUST be performed. 352 The other processes managed in the DTLS record layer MUST follow the 353 DTLS 1.2 [RFC 6347] standard. 355 5. Security Considerations 357 (TBD) 359 6. IANA Considerations 361 This memo includes no request to IANA. 363 7. References 365 7.1. Normative References 367 [RFC7252] Shelby, Z., Hartke, K., and Bormann, C., "The Constrained 368 Application Protocol (CoAP)", RFC 7252, June 2014. 370 [RFC6347] Rescorla, E. and Modadugu, N., "Datagram Transport Layer 371 Security Version 1.2", RFC 4347, January 2012. 373 7.2. Informative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, March 1997. 378 [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 379 256/384 and AES Galois Counter Mode", RFC 5487, March 2009. 381 8. Acknowledgments 383 (TBD) 384 Authors' Addresses 386 Jaeduck Choi 387 National Security Research Institute 388 Daejeon, Korea 389 Email: cjduck@ensec.re.kr 391 Gunhee Lee 392 National Security Research Institute 393 Daejeon, Korea 394 Email: icezzoco@ensec.re.kr 396 Namhi Kang 397 Duksung Women's University 398 Seoul, Korea 399 Email: kang@duksung.ac.kr 401 Seungwook Jung 402 Sonngsil University 403 Seoul, Korea 404 Email: seungwookj@ssu.ac.kr 406 Souhwan Jung 407 Soongsil University 408 Seoul, Korea 409 Email: souhwanj@ssu.ac.kr