[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/