DICE Working Group Jaeduck Choi Internet Draft Gunhee Lee Intended status: Standards Track NSRI Expires: September 23, 2015 Namhi Kang Duksung Women's University Seungwook Jung Souhwan Jung Soongsil University March 24, 2015 Fine-grained Support of Security Services for Constrained Devices using DTLS draft-choi-dice-finegrained-dtls-security-01.txt Abstract This document proposes a method that can selectively apply application data encryption to the DTLS record layer. The CoAP used for resource-constrained devices defines the use of DTLS as a basic security mechanism, and CoAP standard specifies the use of AES_CCM that provides data integrity and confidentiality as a cipher suite for DTLS. However, not all CoAP messages require both data integrity and confidentiality. For example, in case of CoAP messages that include information for turning a light off at home or in a building, or simple ACK information, encryption might not be necessary because such information might not be useful to attackers. Furthermore, from the perspective of effective resource use of resource-constrained devices, reducing the computation load required to perform data encryption every time is necessary. This document describes the methods for CoAP nodes to establish DTLS security channels using the AES_CCM cipher suite, and to selectively apply the encryption function in the DTLS record layer by considering sensitivity to application data leakage. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Choi Expires September 23, 2015 [Page 1] Internet-Draft Fine-grained Support of DTLS Security March 2015 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 23, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 3 2. Terminology ................................................. 4 3. Overview .................................................... 4 4. Protocol Operations ......................................... 7 4.1. DTLS Record Layer Header ............................... 7 4.2. Node Behaviors ......................................... 8 4.2.1. Sender ............................................ 8 4.2.2. Receiver .......................................... 9 5. Security Considerations ..................................... 9 6. IANA Considerations ......................................... 9 7. References ................................................. 10 7.1. Normative References .................................. 10 7.2. Informative References ................................ 10 8. Acknowledgments ............................................ 10 Choi Expires September 23, 2015 [Page 2] Internet-Draft Fine-grained Support of DTLS Security March 2015 1. Introduction IETF CoRE WG has standardized Constrained Application Protocol (CoAP), which can be used for resource-constrained devices [RFC7252]. CoAP defines the use of Datagram Transport Layer Security (DTLS) for device authentication and communication data security, and DTLS specifies TLS_PSK_WITH_AES_128_CCM_8 as a mandatory cipher suite. For a public key-based DTLS cipher suite, CoAP recommends TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. The DTLS cipher suite is negotiated between the CoAP client and server in the process of performing the DTLS handshake protocol. For CoAP application data, data integrity and confidentiality are provided in the DTLS record layer protocol by AES_CCM after completing the DTLS handshake protocol. However, examining whether data integrity and confidentiality should be provided always for CoAP messages in resource-constrained devices is necessary. For example, the necessity of a data confidentiality function to send a CoAP message for turning a light switch off in a building or house is questionable. In the case of simultaneously turning on or off all lights in a building or house, such a function can provide clues for identifying whether residents are present in the building or house to malicious attackers intent on illegal entry. However, eavesdropping on CoAP messages for turning off or on some of the lights might not be significant to malicious attackers. In addition, simple ACK messages received from many devices in a CoAP group communication might not be useful to attackers. Furthermore, from the perspective of effective resource use of resource- constrained devices, reducing the computation load required to execute data encryption every time is necessary. Therefore, to minimize resource consumption of IoT devices, selectively applying the data confidentiality function by considering the sensitivity to leakage of application data is necessary. The strain on memory capacity for loading an encryption module on IoT devices should also be considered. TLS defines the cipher suites that provide data integrity only using hash functions such as TLS_PSK_WITH_NULL_SHA256 [RFC5487]. Only integrity function can be provided to CoAP messages in the DTLS record layer after completing the DTLS handshake protocol with TLS_PSK_WITH_NULL_SHA256. However, if TLS_PSK_WITH_AES_128_CCM_8 and TLS_PSK_WITH_NULL_SHA256 are implemented on resource-constrained devices, burden on memory capacity can occur compared to devices that have only implemented TLS_PSK_WITH_AES_128_CCM_8 because the SHA256 module also has to be loaded. Choi Expires September 23, 2015 [Page 3] Internet-Draft Fine-grained Support of DTLS Security March 2015 In selectively applying the confidentiality function of CoAP messages, DTLS sessions would be re-established frequently. For example, to send a CoAP message that needs encryption, CoAP nodes will establish the DTLS session to the TLS_PSK_WITH_AES_128_CCM_8 or TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suits. While the DTLS session is maintained during the effective period, if a CoAP message that does not require encryption has to be sent, the CoAP nodes will terminate the current DTLS session and resume the DTLS session with the TLS_PSK_WITH_NULL_SHA256 cipher suite. In other words, because of unpredictable IoT service scenario characteristics (the characteristics where sensitivities to data leakage are different), situations can occur often whereby CoAP nodes have to re-establish DTLS sessions for different cipher suites that provide functions for both data integrity and confidentiality, and functions for data integrity only. This becomes a major cause for wasting resources when applying DTLS to CoAP nodes. This document describes a method for selectively applying encryption functions in the DTLS record layer by considering the sensitivity to leakage of application data without changing the DTLS cipher suite, which is defined as the default in the CoAP protocol. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Overview This section describes a basic concept of the proposed method. When security negotiation is performed with the default cipher suite during the DTLS handshake protocol between a CoAP client and server, the two nodes complete the preparation for providing the CoAP message data integrity in the DTLS record layer, or for providing both data integrity and confidentiality. Here, how should the CoAP message that needs to provide the data integrity function only in the DTLS record be defined? This question is not covered in the scope of this standard. An example of the solution of the question is the CoAP message that has to provide the integrity function only, and which can be set in advance in the IoT service definition and development stages. Furthermore, such CoAP messages can be Choi Expires September 23, 2015 [Page 4] Internet-Draft Fine-grained Support of DTLS Security March 2015 identified in the DTLS record layer using a bit flag value or optional field that is defined separately in the existing CoAP header. In the case of CoAP messages that do not require encryption, the CoAP node generates an authentication tag value of the CoAP message in the DTLS record layer, and sends the CoAP message to the corresponding CoAP node without performing encryption (only the process shown in Fig. 1(a) is performed). For CoAP messages that require encryption, an authentication tag value is generated in the DTLS record layer, and both the CoAP message and authentication tag value are encrypted (the processes shown in Figs. 1(a) and 1(b) are performed) and sent. Here, the sender node of the CoAP message sets the encryption flag value of the DTLS record protocol header to "0" (integrity is provided) or "1" (integrity and confidentiality are provided); depending on the flag value, the receiver node of the CoAP message performs the process of integrity verification only or the processes of decryption and integrity verification. Fig. 2 shows the overall flow of the proposed method. Choi Expires September 23, 2015 [Page 5] Internet-Draft Fine-grained Support of DTLS Security March 2015 +-------+---------------------+-----------------------------------+ | Nonce | Associated data | Plaintext | +-------+---------------------+-----------------------------------+ | V +------+------+------+ +------+ | B_0 | B_1 | B_2 | . . . | B_r | +------+------|------+ +------+ | V +--------+ K ---> | CMAC | +--------+ | V +------+ | Tag | +------+ (a) Authentication +------------------------------------------------+ +------+ | Plaintext | |Ctr_0 | +------------------------------------------------+ +------+ | | | V | +---------+ | K --> | Encrypt | | +---------+ V | +--------+ V Ctr_1, ..., Ctr_m -->| CTR | +-----------+ K -->| | K --> | MSB(Tlen) | +--------+ +-----------+ | | | +------+ V | | Tag | --> XOR | +------+ | V V +------------------------------------------------+ +------+ | | | | +------------------------------------------------+ +------+ | | +-------------------------Ciphertext--------------------------+ (b) Encryption Figure 1: AES_CCM Block Diagram Choi Expires September 23, 2015 [Page 6] Internet-Draft Fine-grained Support of DTLS Security March 2015 CoAP Client CoAP Server | | | | | <========== DTLS Handshake Protocol ===========> | | with TLS_PSK_WITH_AES_CCM_8 | | | | DTLS Record Protocol | +---|------------------------------------------------------|---+ | | | | | | | | | | Encryption_Flag = 0 (Msg Auth.) | | | |<---------------------------------------------------->| | | | | | | | | | | // // | | | | | | | Encryption_Flag = 1 (Msg. Enc. & Auth.) | | | |<---------------------------------------------------->| | | | | | | | | | +---|------------------------------------------------------|---+ | | Figure 2: Protocol Flow 4. Protocol Operations 4.1. DTLS Record Layer Header This document defines the encryption flag (F) in the DTLS record layer header to identify whether integrity only or both integrity and confidentiality functions are supported for the messages exchanged between the CoAP nodes through the DTLS security channel. In this document, the top level one bit of the "epoch" field in the DTLS record header is used as a bit to identify whether to apply the encryption. Figure 3 shows the DTLS record layer header format defined in this document, and Table 1 lists the definition of the encryption flag. Choi Expires September 23, 2015 [Page 7] Internet-Draft Fine-grained Support of DTLS Security March 2015 +-----------------------------------------------------------------+ | 1 Byte | 2 Byte | 2 Byte | 6 Byte | 2 Byte | | | +-----------------------------------------------------------------+ | Content | Version | epoch | seq_ | Length | Ciphertext | MAC | | Type | Ma | Mi | | number | | (Enc) |(Enc)| +---------+---------+--------+--------+--------+------------+-----+ | | | | +--------+ | V 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| epoch | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The encryption flag (F) in the DTLS record layer header +----------+------------------------------------------------------+ | F | Description | +----------+------------------------------------------------------+ | 0 | integrity support | +----------+------------+-----------------------------------------+ | 1 | both integrity & encryption support | +----------+------------------------------------------------------+ Table 1: Encryption flag (F) description 4.2. Node Behaviors 4.2.1. Sender A sender that sends a CoAP message MUST check whether the confidentiality function of the CoAP message is to be provided (not in the scope of this standard document). When only the integrity function has to be provided for the CoAP message, the process of generating an authentication tag value of the CoAP message MUST be performed using the traditional AES_CCM procedure in the DTLS record layer, and the encryption function MUST NOT be performed. The sender MUST set the flag "F" of the DTLS Choi Expires September 23, 2015 [Page 8] Internet-Draft Fine-grained Support of DTLS Security March 2015 record layer header to "0." Then, the sender MUST send the CoAP message and authentication tag value to the CoAP receiver. When both the integrity and confidentiality functions have to be provided for the CoAP message, according to the AES_CCM procedure, the CoAP message authentication tag value MUST be generated and the message MUST be encrypted in the DTLS record layer. Prior to sending the encrypted message, CoAP MUST set the flag "F" of the DTLS record layer header to "1." The sender then MUST send the encrypted CoAP message to the CoAP receiver. The other processes managed in the DTLS record layer MUST follow the DTLS 1.2 [RFC6347] standard. 4.2.2. Receiver The receiver node that receives the CoAP message through the DTLS security channel MUST check the value of the flag "F" in the DTLS record layer header. If the flag value is "0," only the authentication tag value of the CoAP message MUST be verified; if the flag value is "1," the processes to decrypt the CoAP message and verify the authentication tag value MUST be performed. The other processes managed in the DTLS record layer MUST follow the DTLS 1.2 [RFC6347] standard. 5. Security Considerations (TBD) 6. IANA Considerations This memo includes no request to IANA. Choi Expires September 23, 2015 [Page 9] Internet-Draft Fine-grained Support of DTLS Security March 2015 7. References 7.1. Normative References [RFC7252] Shelby, Z., Hartke, K., and Bormann, C., "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC6347] Rescorla, E. and Modadugu, N., "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 7.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA- 256/384 and AES Galois Counter Mode", RFC 5487, March 2009. 8. Acknowledgments (TBD) Choi Expires September 23, 2015 [Page 10] Internet-Draft Fine-grained Support of DTLS Security March 2015 Authors' Addresses Jaeduck Choi National Security Research Institute Daejeon, Korea Email: cjduck@ensec.re.kr Gunhee Lee National Security Research Institute Daejeon, Korea Email: icezzoco@ensec.re.kr Namhi Kang Duksung Women's University Seoul, Korea Email: kang@duksung.ac.kr Seungwook Jung Sonngsil University Seoul, Korea Email: seungwookj@ssu.ac.kr Souhwan Jung Soongsil University Seoul, Korea Email: souhwanj@ssu.ac.kr Choi Expires September 23, 2015 [Page 11]