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= , hello_rand | | | |<---------------------------------------------------------------| | ACK; MsgID = n; Token = m; | | Payload = AES{(ext_hello_rand XOR k_c) | server_rand}_Y; | | Response = 2.01 CREATED /session/ | | (if ID not-found then 4.01 UNAUTHORIZED) | | | |--------------------------------------------------------------->| | POST: CON; MsgID = n+1; Token = m; | | AUTH = true; | | AUTH-MSG-TYPE = 1; | | URI= /session/ | | 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, . [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]