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

Versions: 00 01

dice                                                   A. Bhattacharyya
Internet Draft                                                  T. Bose
Intended status: Standards Track                                A. Ukil
Expires: September 2018                                S. Bandyopadhyay
                                                                 A. Pal
                                         TATA CONSULTANCY SERVICES LTD.
                                                          March 3, 2018



        Lightweight Establishment of Secure Session (LESS) on CoAP
                 draft-bhattacharyya-dice-less-on-coap-01


   Abstract

   Secure yet lightweight protocol for communication over the Internet
   for constrained node networks (CNN) is a pertinent problem.
   Constrained Application Layer Protocol (CoAP) mandates the use of
   Datagram Transport Layer Security (DTLS) for a secure transaction
   over CoAP. But DTLS is not a candidate technology for CNNs by
   design. The DTLS handshake overhead to establish the credentials for
   a session between two end-points in a CNN may not be resource
   efficient. There are ongoing efforts to secure one-time exchanges by
   ensuring object security at the application layer. But a composite
   standardized mechanism for resource-efficient end-to-end security
   credential establishment is much needed to cater both one-time
   exchanges as well as exchanges over a session. DTLS is essentially a
   combination of two operations: (1) the session protocol to establish
   the credentials (and this is the resource heavy part), (2) the
   record protocol to protect the information (this is the
   cryptographic part). This draft proposes to distribute the security
   responsibilities such that the session establishment happens in the
   application layer, leveraging the lightweight semantics of CoAP, and
   the record layer encryption happens by reusing the existing DTLS
   record-layer protocol. This way the proposed mechanism enables a
   resource-efficient session establishment mechanism besides reusing
   the existing DTLS encryption. Assuming a Pre-Shared Key (PSK)
   environment, this draft proposes an embedding of handshake for
   resource efficient end-to-end session establishment into CoAP. The
   session establishment procedure produces the necessary and
   sufficient inputs for seamless operation of the DTLS record-layer to
   secure the channel. Also, this mechanism ensures a direct security
   association between the end-applications for systems using
   middleboxes like proxies and/or gateways which may not be always
   trusted. The proposed approach provides a mechanism to securely
   traverse through such middleboxes through an end-to-end trusted
   channel.



Bhattacharyya, et al. Expires September 3, 2018                [Page 1]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


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.

   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."

   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.

   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 3, 2018.

Copyright Notice

   Copyright (c) 2018 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.


Bhattacharyya, et al. Expires September 3, 2018                [Page 2]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


Table of Contents


   1. Introduction...................................................3
      1.1. Application scenario......................................3
         1.1.1. Session based secure communication over CNN..........4
      1.2. State of standardization for securing CoAP................4
      1.3. Proposed approach.........................................5
   2. The Algorithm..................................................7
      2.1. Implementation on CoAP....................................9
   3. Enabling channel security: Re-using DTLS record encryption....11
   4. Experimental Results..........................................13
   5. Session time-out and resumption...............................15
   6. Security Considerations.......................................16
   7. References....................................................16
      7.1. Normative References.....................................16
      7.2. Informative References...................................17

1. Introduction

   Secure communication between two end-points in a CNN typical for
   Internet of Things (IoT)/ Machine to Machine (M2M) communication
   must be resource-efficient. The resource-efficiency must be ensured
   while establishing the security credentials. The process should be
   acceptable not only for communications like a single-shot small
   sensor data update, but also for exchanges which may happen over a
   session.

   Furthermore, when the end-to-end channel has to go through
   middleboxes, like proxies or gateways, there may be need to
   establish a direct security association between the end-points and
   the middleboxes may not always be trusted. This is also useful if
   one of the end-point application layer connects over a non-IP link
   via a gateway that translates the connection to an IP network.

   The next subsections describe typical application scenario, current
   status of standardization on this aspect around CoAP [RFC7252] and
   the proposed approach.

1.1. Application scenario

   [I.D.draft-friel-tls-atls] describes the scenarios which would need
   an end-to-end direct security association over a secure channel
   through middlebox.

   Next we describe exemplary application which may need to establish a
   secure channel for session based exchange over a CNN.


Bhattacharyya, et al. Expires September 3, 2018                [Page 3]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


1.1.1. Session based secure communication over CNN

   Scenario 1:

   Vehicles post their instant locations to the smart traffic
   application server of the concerned authority in an intelligent
   traffic system (ITS) for smart city applications. Locations may be
   updated through a GPS sensor on vehicle which connects to the
   Internet over cellular network. This requires a resource efficient,
   low-latency secure session establishment between the sensor on
   vehicle and the end-server to ensure a secure end-to-end channel all
   through the journey of each individual vehicle. Session time-out and
   refreshment of security credentials is also needed to prevent
   passive attacks through session activity analysis. The vehicles
   would have to move through different terrains with highly
   fluctuating channel conditions. The session establishment procedure
   must be capable of establishing a successful secure session even
   under lossy condition.

   Scenario 2:

   Another example could be real-time update of sensitive and critical
   health parameters of a patient being moved to a hospital in an
   emergency vehicle. The health information is communicated by sensor
   devices which connects via an onboard gateway. The sensor
   establishes a direct security association with the specialist doctor
   portal at the hospital. Continuous health parameters are transferred
   over a secure session through a secure channel. The resource
   efficiency requirements described in the above scenario is also
   valid in this case. This kind of scenario will also need to have a
   robust yet resource-efficient mechanism for establishing and
   refreshing session security credentials under intermittent channel
   conditions.

1.2. State of standardization for securing CoAP

   The Constrained Application Protocol (CoAP)[RFC7252] specification
   mandates the use of DTLS for secure connection establishment between
   end-points. Sine full PKI based systems with certificate exchange,
   etc. prove too resource heavy, CoAP proposes different flavours of
   DTLS. DTLS with Pre-Shared Key (PSK) is the option with minimum
   resource requirement. However, even in PSK mode, the communication
   overhead for key-negotiation prior to connection establishment may
   prove costly in certain constrained environments. In fact, by
   default, DTLS adds to the connection overhead compared to the base
   protocol TLS. This is caused due to cookie exchanges introduced to
   combat certain DoS attacks as specified in Section 4.2.1 of


Bhattacharyya, et al. Expires September 3, 2018                [Page 4]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   [RFC6347]. Also, individual DTLS messages may lead to uncontrolled
   fragmentation resulting into degraded network performance.

   There are ongoing efforts [I.D. draft-ietf-core-object-security] to
   secure individual CoAP payload using CBOR Object Signing and
   Encryption (COSE) [RFC8152]. This approach also takes care of
   creating end-to-end security association through middleboxes. But
   this is not designed for a session-based communication which might
   need protection of the complete application layer message over an
   end-to-end secure channel without terminating the security
   association at the transport/ application-layer middleboxes.

1.3. Proposed approach

   The draft proposes a cross-layer approach to distribute the
   responsibilities for secure channel establishment in the following
   manner:

   i) CoAP, through its RESTful request/response semantics, takes care
   of mutual authentication of the end-points and establishment of the
   session security parameters (like the session keys).

   ii) Once the session is established, the transports at the end-
   points reuse the DTLS record encryption mechanism to ensure
   standardized channel security of the full CoAP messages throughout
   the session.

   Figure 1 illustrates the responsibility of different layers in the
   proposed complete security suit.




















Bhattacharyya, et al. Expires September 3, 2018                [Page 5]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   +-------------------------------------+
   | CoAP (Establishes secure session)   |
   +-------------------------------------+
                  ||
                  \/
   +-------------------------------------+
   | Interface                           |
   | (Arranges the session parameters)   |
   +-------------------------------------+
                  ||
                  \/
   +-------------------------------------+
   | Secure Transport (Reuses DTLS       |
   | record encryption using the session |
   | parameters for channel security)    |
   +-------------------------------------+

   Figure 1: Illustrating the across-the-layer distribution of
   responsibilities.



   As an initial effort, point (i) above is achieved by assuming that
   the end-points are pre-provisioned with a pre-shared secret. An
   exemplary computationally simple yet robust challenge-response
   scheme for establishing a secure session between two endpoints is
   proposed. The secure session establishment process comprises of
   mutual authentication of the endpoints and sharing the session-keys
   between the endpoints. (It is also to be observed that DTLS-PSK only
   allows server to authenticate the client. The reverse does not
   happen.) The scheme completes the session establishment in just 4
   handshake messages. The full handshake can be modelled as just 2
   pairs of CoAP request/response. The maximum possible application
   layer message size during the handshake is kept low to avoid
   unwanted fragmentation at the lower layers for most of the cases.
   Thus the scheme is low in communication overhead. So, this draft
   enables CoAP with an inherent mechanism of secure session
   establishment. While the established credentials enables the system
   to reuse DTLS record-layer, it may well be used for only 'object-
   security' over CoAP. The later will be useful in scenarios where
   CoAP is deployed over a transport which does not have DTLS-like
   security.

   The advantage of the proposed scheme is demonstrated through
   experimental results presented in Section 4.




Bhattacharyya, et al. Expires September 3, 2018                [Page 6]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   This draft is an extension of the initial work presented in [I.D.
   core-coap-lite-auth].

   The basic approach proposed in this draft may be extended to more
   complex security association beyond PSK.

2. The Algorithm

   Algorithm-1 below describes the generic challenge-response based
   algorithm for secure session establishment. Figure 2 illustrates the
   steps of Algorithm-1.

   Interpretation of the expressions used in Algorithm-1 are explained
   below:

   -> AES{expr}_Y : AES_128_CCM_8 encryption of 'expr' with key Y

   ->      |      : Concatenation operation

   ->   {0,1}^N   : A binary string of N bits

   -> vect[N1:N2] : Accessing bit position N1 to N2 of bit vector
   'vect'.

-----------------------------------------------------------------------
                            Algorithm-1
-----------------------------------------------------------------------
   **Step 0: Pre-sharing secret (prerequisite)-

   A 128 bit secret (Y) is shared between client C_i and server S
   offline at provisioning phase.

   ** Step 1 - Session initiation:

   C_i initiates the session by sending a HELLO to S. The HELLO
   comprises of #Ci and 'hello_rand'. (#Ci is the unique client ID and
   hello_rand is a random number of 12 bytes.)

   ** Step 2 - Server challenge:

   S  responds as:   AES {(ext_hello_rand XOR (k_c | server_rand))}_Y
   (Here, k_c = {0,1}^128 is the client-write key, server_rand= {0,1
   }^96; ext_hello_rand = hello_rand | hello_rand[0:31]).

   [Optional: S may perform a table look-up to check if the #Ci is
   valid before challenging client. If #Ci is not valid then the
   handshake does not proceed further.]


Bhattacharyya, et al. Expires September 3, 2018                [Page 7]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   ** Step 3 - Client response and challenge:

   Ci returns: AES{(server_rand | client_rand)}_k_c
   (Here, client_rand = {0,1}^96 is a random number generated  by the
   client).

   Thus if Ci is able to decipher the challenge from S in step 2 then
   it will have the right 'k_c' and 'server_rand' which is embedded in
   the response. This completes the client side key exchange. Then, Ci
   responds as well as challenges S with random number 'client_rand'
   encrypted with the client-write key k_c.

   ** Step 4 - Server response:

   Server verifies server_rand from client with its own copy and
   returns: AES {(ext_server_rand XOR (k_s  | client_rand))}_Y
   (Here, ext_server_rand = server_rand | server_rand[0:31] and k_s =
   {0,1}^128 is the server-write key).

   ** Result:

   If server_rand from S satisfies Ci then the mutual authentication is
   completed and Ci gets the server-write key k_s with which the server
   messages are to be deciphered for a given session. Thus, after the
   handshake is over, both the end-points have mutually agreed on the
   server-write and client-write key pair {k_s, k_c} for a given
   session.

   Note: The AES encryption is implemented as AES_128_CCM_8. CCM mode
   would need 12 bit nonce for each encryption and an additional data.
   'hello_rand', 'server_rand' and 'client_rand' serves as the required
   nonce values in steps 2, 3 and 4 respectively. The 'additional data'
   can be the header for each message of the application layer protocol
   (ex. CoAP) on which the scheme is adapted.

---------------------------- END of Algorithm 1 -----------------------













Bhattacharyya, et al. Expires September 3, 2018                [Page 8]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   Ci(Client #i)                                     S(Server)
   |                                                     |
   |                                                     |
   +---------------------------------------------------->|
   | Hello, #Ci, hello_rand                              |
   |                                                     |
   |<----------------------------------------------------|
   | AES{(ext_hello_rand XOR k_c) | server_rand}_Y       |
   |                                                     |
   |---------------------------------------------------->|
   | AES{server_rand | client_rand}_k_c                  |
   |                                                     |
   |<----------------------------------------------------|
   | AES{(ext_server_rand XOR k_s)  | client_rand}_Y     |
   |                                                     |

   Figure 2: Illustration of steps in Algorithm-1


2.1. Implementation on CoAP

   This section describes how the proposed scheme can be implemented on
   CoAP. The inherent reliable delivery feature of CoAP helps easy
   implementation of the proposed scheme against packet loss.

   Two options are introduced for POST method to be used for
   authentication as described in Table 1 and 2.

   +-----+---+---+---+---+--------------+--------+--------+---------+
   | No. | C | U | N | R | Name         | Format | Length | Default |
   +-----+---+---+---+---+--------------+--------+--------+---------+
   | TBD | X | X | - |   | Auth         |  empty |    0   | (none)  |
   +-----+---+---+---+---+--------------+--------+--------+---------+
   | TBD | X | X | - |   | Auth-Msg-Type|  uint  |    1   | (none)  |
   +-----+---+---+---+---+--------------+--------+--------+---------+

                           Table 1: Option Properties












Bhattacharyya, et al. Expires September 3, 2018                [Page 9]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   +--------------+--------+------------------------------------------+
   | Name         | Method |                 Description              |
   +--------------+--------+------------------------------------------+
   | Auth         |        |If present, indicates that the POST       |
   |              |        |request carries authentication payload.   |
   +--------------+        +------------------------------------------+
   |              |        |Always to be used with 'Auth'. Value of   |
   |              | POST   |the option indicates the type of          |
   |              |        |authentication request. Value in this     |
   | Auth-Msg-Type|        |field determines the response by sever    |
   |              |        |against a POST request with 'Auth'. It can|
   |              |        |assume two values:                        |
   |              |        |0 (auth-init) -> Authentication initiation|
   |              |        |with hello from client,                   |
   |              |        |1 -> response-against-challenge.          |
   +--------------+--------+------------------------------------------+
                        Table 2: Description of the options.

   Figure 3 illustrates the handshake over CoAP.






























Bhattacharyya, et al. Expires September 3, 2018               [Page 10]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   Client #i                                                   Server
   |                                                                |
   |                                                                |
   +--------------------------------------------------------------->|
   | POST: CON; MsgID = n; Token = m;                               |
   |       URI=/session;                                            |
   |       AUTH = true;                                             |
   |       AUTH-MSG-TYPE = 0;                                       |
   |       Payload= <Device ID>, hello_rand                         |
   |                                                                |
   |<---------------------------------------------------------------|
   | ACK; MsgID = n; Token = m;                                     |
   | Payload = AES{(ext_hello_rand XOR k_c) | server_rand}_Y;       |
   | Response = 2.01 CREATED /session/<sessionID>                   |
   | (if ID not-found then 4.01 UNAUTHORIZED)                       |
   |                                                                |
   |--------------------------------------------------------------->|
   | POST: CON; MsgID = n+1; Token = m;                             |
   |       AUTH = true;                                             |
   |       AUTH-MSG-TYPE = 1;                                       |
   |       URI= /session/<sessionID>                                |
   | Payload = AES{server_rand | client_rand}_k_c                   |
   |                                                                |
   |<---------------------------------------------------------------|
   | ACK; MsgID = n+1; Token = m;                                   |
   | Payload = AES{(ext_server_rand XOR k_s)  | client_rand}_Y      |
   | Response = 2.04 CHANGED                                        |
   |            (Client authenticated)                              |
   | (if received server_rand does not match with                   |
   |  server copy then  4.01 UNAUTHORIZED)                          |
   |                                                                |

   Figure 3: Proposed CoAP specific implementation of Algorithm-1.


3. Enabling channel security: Re-using DTLS record encryption

   At the end of the above described session establishment process both
   client and server has the necessary key pair {k_s, k_c}. This might
   suffice for providing 'object security'.

   However, it may be possible to provide a solution by re-using the
   per-session record-encryption mechanism as deployed in DTLS. To
   achieve this we need to fill-up the DTLS session parameter structure
   for each session prior to record encryption.

   To do this we essentially need the encryption tuple:


Bhattacharyya, et al. Expires September 3, 2018               [Page 11]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


    {server-write key, client-write key, server_IV, client_IV}.

   We already have the first two parameters as {k_s, k_c}. Computation
   of server_IV and client_IV has to happen at both the endpoints.
   There can be several complex mathematical functions to do this
   computation. Figure 4 illustrates a very naive way.

   <-----------------------12 Bytes---------------------->
   +-----------------------------------------------------+
   |                      client_rand                    |
   +-----------------------------------------------------+

                             XOR

   +-----------------------------------------------------+
   |                      server_rand                    |
   +-----------------------------------------------------+

                              ||
                              \/

   <-----------------------12 Bytes---------------------->
   +-----------------------------------------------------+
   | <--- 4 Bytes ---> | <--- 4 Bytes ---> |             |
   +-----------------------------------------------------+
            /\                /\
            ||                ||
          client_IV         server_IV

   Figure 4: Calculating client_IV and server_IV.


   Figure 5 illustrates how the session parameters for the proposed
   scheme can directly map to the DTLS session parameters structure
   thus enabling the record encryption process for each session.














Bhattacharyya, et al. Expires September 3, 2018               [Page 12]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018



   +-----------------+ +----------+ +--------------------------------+
   |Session ID       | |Pre-shared| |{k_s, k_c, server_IV, client_IV}|
   |(Shared by server| |secret (Y)| +--------------------------------+
   | as part of a    | +----------+              ||    ||
   | temp URI path)  |      | |                  ||    ||
   +-----------------+      | |                  ||    ||
     ||                     | +-------------+    ||    ||
     ||                     +--------------+|    ||    ||
     \/                                    \/    \/    \/
   +-----+------+---------+-------------+------+-----+-----+----------+
   |Sess.|Peer  |Compress.|Cipher       |Master|Read |Write|Seq.      |
   |ID   |Cert. |Method = | suit =      |secret|state|state|No.       |
   |     |= NULL|NULL     |AES_128_CCM_8|      |     |     |(implicit)|
   +-----+------+---------+-------------+------+-----+-----+----------+


   Figure 5: Mapping of different session parameters to the DTLS
   session parameter structure for PSK mode.


   Once the session parameter structure is filled, conventional
   symmetric DTLS-PSK record encryption method can be used to provide
   channel encryption to the full application layer message (data +
   header).

   Thus the above discussions, fundamentally, propose a cross layer
   approach (Figure 1) - secure session established in a lightweight
   manner at the application layer (CoAP) and session wise channel
   encryption is performed at the transport layer using DTLS record
   encryption method.

4. Experimental Results

   Experiments were performed in an emulated WAN environment which
   allows to control the network parameters. The session establishment
   process was run for about a thousand times in a loop for both
   standard Californium DTLS-PSK implementation and the proposed
   solution. Performance measurement was carried out in terms of the
   average number of bytes over the media and average latency per
   session establishment under different packet errors. A third
   parameter was the percentage of successful session establishment
   under different packet errors. End-to-end bandwidth was set at a
   minimal 9.6 Kbps.Table 3-5 tabulates the different results.





Bhattacharyya, et al. Expires September 3, 2018               [Page 13]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


                   +----------+-------------+---------+
                   | Pkt.Loss | LESS on CoAP| DTSL-PSK|
                   +----------+-------------+---------+
                   |   0%     |    0.4018s  | 0.23s   |
                   +----------+-------------+---------+
                   |   5%     |    2.20s    | 26.44s  |
                   +----------+-------------+---------+
                   |   10%    |    6.00s    | 29.85s  |
                   +----------+-------------+---------+
                   |   15%    |    13.36s   | 47.29s  |
                   +----------+-------------+---------+
                   |   20%    |    26.864s  | 76.37s  |
                   +----------+-------------+---------+

   Table 3: Performance comparison in terms of average latency per
   session establishment process.

                   +----------+-------------+---------+
                   | Pkt.Loss | LESS on CoAP| DTSL-PSK|
                   +----------+-------------+---------+
                   |   0%     |    435.98B  |   853B  |
                   +----------+-------------+---------+
                   |   5%     |   453.05B   | 962.55B |
                   +----------+-------------+---------+
                   |   10%    |    476.17B  | 1030.02B|
                   +----------+-------------+---------+
                   |   15%    |    523.34B  | 1094.71B|
                   +----------+-------------+---------+
                   |   20%    |    566.1386B| 1219.63B|
                   +----------+-------------+---------+

   Table 4: Performance comparison in terms of average number of bytes
   exchanged over the physical media per session establishment process.
















Bhattacharyya, et al. Expires September 3, 2018               [Page 14]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


                   +----------+-------------+---------+
                   | Pkt.Loss | LESS on CoAP| DTSL-PSK|
                   +----------+-------------+---------+
                   |   0%     |     100%    |    100% |
                   +----------+-------------+---------+
                   |   5%     |     100%    |   0.92% |
                   +----------+-------------+---------+
                   |   10%    |     100%    |   0.91% |
                   +----------+-------------+---------+
                   |   15%    |     100%    |   0.87% |
                   +----------+-------------+---------+
                   |   20%    |     100%    |   0.78% |
                   +----------+-------------+---------+

   Table 5: Rate of successful session establishment

   The above results establish that the proposed method has significant
   improvement in terms of different performance metrics. One point to
   be noted here is, the latency with 0% packet loss (Table 3) is
   marginally higher in case of LESS on CoAP. This is attributed to the
   fact that the latency measurement incorporates the computation time
   at the endpoints. Since, LESS deploys encryption-decryption routines
   during session establishment unlike DTLS-PSK so we see a marginal
   higher latency under ideal condition. However, as the channel
   worsens that marginal computational time loses any significance.

   Another important point to be observed is the rate of unsuccessful
   session establishment attempts as displayed in Table 5. It has been
   observed that with increasing packet loss final 'flights' in DTLS
   tend to fail the integrity check.

5. Session time-out and resumption

   Session time-out is proposed to enable re-negotiation of the key.
   This would help combat the chosen-cipher-text attack. The detail
   handshake is TBD. It is to be mentioned that when the system deploys
   the full proposed channel security, the control needs to go back
   from transport to application. A possible way to identify a session
   timeout response from the server and switching back the control to
   application layer may be through handling the DTLS alarm messages in
   a clever way (or, proposing a new DTLS alarm message for this
   purpose).







Bhattacharyya, et al. Expires September 3, 2018               [Page 15]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


6. Security Considerations

   The draft itself deals with lightweight security. This section
   briefly mentions the resilience of the proposed mechanism against
   some common attacks.

   * Passive attack due to traffic analysis:

   Frequently changing the session parameters may help prevent this
   kind of attack. Also, the session keys are obfuscated within the
   payloads. So, even if one gets hold of Y, getting the session key
   would need 2^256 or approximately 1.16*10^77 attempts.

   * Denial of Service (DoS):

   DoS launched by an attacker can have two fold effects: 1. Consuming
   resources on the server by transmitting a series of session
   initiation requests. 2. Using the server as an amplifier by issuing
   session initiation requests with forged source leading to message
   flooding.

   The proposed challenge/response mechanism takes care of both of the
   attacks. Any such attack should be ineffective just after the server
   challenge.

   However, deliberate too many simultaneous invalid attempts to
   establish a session may jeopardise the server.

   * Replay protection:

   The DTLS record encryption has inherent protection against replay
   attacks. Thus the proposed scheme leverages that capability by
   reusing the DTLS record encryption for full channel security.

7. References

7.1. Normative References

   [RFC7252]

   Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application
   Protocol (CoAP)", RFC 7252, June, 2014

   [RFC6347]





Bhattacharyya, et al. Expires September 3, 2018               [Page 16]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security
   Version 1.2", RFC 6347, January 2012.

   [I.D.draft-friel-tls-atls]

   Friel, O., Barnes, R., Pritikin, M., Tschofenig, H. and Baugher, M.,
   "Application-Layer TLS (ATLS)", draft-friel-tls-atls-00, January
   2018.

7.2. Informative References


   [I.D.core-coap-lite-auth]

   Bhattacharyya, A., Bandyopadhyay, S., Ukil, A., Bose, T. and Pal,
   A.," Lightweight mutual authentication for CoAP (WIP)", draft-
   bhattacharyya-core-coap-lite-auth-00, March 3, 2014

   [I.D. draft-ietf-core-object-security]

   Salender, G., Mattsson, J., Palombini, F. and Seitz, L.," Object
   Security for Constrained RESTful Environments (OSCORE)", draft-ietf-
   core-object-security-08, January 22, 2018.

   [RFC8152]

   Schaad, J., "CBOR Object Signing and Encryption (COSE)",
   RFC 8152, DOI 10.17487/RFC8152, July 2017,
   <https://www.rfc-editor.org/info/rfc8152>.

   [PITSAC-AINA]

   Bhattacharyya, A., Bose, T., Bandyopadhyay, S., Ukil, A. and Pal,
   A., " LESS: Lightweight Establishment of Secure Session", PITSaC(in
   conjunction with AINA), 2015.

   [PERCOM-Workshop]

   Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., " Auth-
   Lite: Lightweight M2M Authentication reinforcing DTLS for CoAP",
   IEEE PERCOM Workshops, 2014.

   [ASPI-Ubicomp]





Bhattacharyya, et al. Expires September 3, 2018               [Page 17]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


   Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A.,
   "Lightweight security scheme for vehicle tracking system using
   CoAP", ACM ASPI-Ubicomp Adjunct, 2013.

   [I.D.rescorla-sec-cons-05]

   Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on
   Security Considerations", draft-rescorla-sec-cons-05, April 2002








































Bhattacharyya, et al. Expires September 3, 2018               [Page 18]


Internet-Draft  draft-bhattacharyya-dice-less-on-coap-01     March 2018


Authors' Addresses

   Abhijan Bhattacharyya
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: abhijan.bhattacharyya@tcs.com



   Soma Bandyopadhyay
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: soma.bandyopadhyay@tcs.com



   Arijit Ukil
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: arijit.ukil@tcs.com


   Tulika Bose
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: tulika.bose@tcs.com



   Arpan Pal
   Tata Consultancy Services Ltd.
   Kolkata, India

   Email: arpan.pal@tcs.com











Bhattacharyya, et al. Expires September 3, 2018               [Page 19]


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