dice A. Bhattacharyya Internet Draft S. Bandyopadhyay Intended status: Experimental A. Ukil Expires: October 2015 T. Bose A. Pal TATA CONSULTANCY SERVICES LTD. April 17, 2015 Lightweight Establishment of Secure Session (LESS) on CoAP draft-bhattacharyya-dice-less-on-coap-00 Abstract This draft presents an experimental work proposing a lightweight secure session establishment scheme to mutually authenticate two endpoints and share the session key. It works on symmetric cryptosystem with pre-shared secret between the endpoints during provisioning. The main algorithm is proposed as a generic concept. This draft further describes how the generic concept can be modeled as simple CoAP request/response pairs. Thus the proposed scheme enables CoAP with inherent security which might be useful for object security without requiring any secure transport. Still further, this draft demonstrates how the scheme could be integrated with the record encryption mechanism of DTLS-PSK. It reuses the DTLS session parameter structure without any modification. Thus channel security for the whole application message can be provided. So the scheme is a cross-layer mechanism such that the session establishment is performed in CoAP and channel encryption is performed in the transport layer reusing only the record encryption mechanism of DTLS-PSK. The scheme uses all standard encryption libraries. The lightweight nature and performance improvement is demonstrated with some supporting comparative results. 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 Bhattacharyya, et al. Expires October 17, 2015 [Page 1] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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 October 17, 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. The Algorithm..................................................4 2.1. Implementation on CoAP....................................6 3. Enabling channel security: Re-using DTLS record encryption.....8 4. Experimental Results..........................................10 5. Session time-out and resumption...............................12 6. Security Considerations.......................................13 7. References....................................................13 Bhattacharyya, et al. Expires October 17, 2015 [Page 2] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 7.1. Normative References.....................................13 7.2. Informative References...................................14 1. Introduction 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 [RFC6347]. Also, individual DTLS messages may lead to uncontrolled fragmentation resulting into degraded network performance. First aspect of this draft is a computationally simple yet robust challenge-response scheme for establishing a secure session between two endpoints. The secure session establishment process comprises of mutual authentication of the endpoints and sharing the session-keys between the endpoints. The endpoints are pre-provisioned with a pre- shared secret. (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 which may well be used for 'object-security' over CoAP. This will also be useful in scenarios where CoAP is deployed over a transport which does not have DTLS-like security. The second aspect of the draft is a cross-layer approach to provide a light-weight channel security to the full application layer message comprising data and header. To achieve this the present draft adapts the record encryption mechanism as deployed in DTLS for a DTLS session. This draft proposes a very simple mechanism to compute the session parameters and reuse the DTLS session structure without any modification. This way the present scheme can be easily integrated with an existing system deploying DTLS by reusing most of the modules and adding very minimal code to implement the whole scheme. Bhattacharyya, et al. Expires October 17, 2015 [Page 3] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 Figure 1 illustrates the responsibility of different layers in the proposed complete security suit. +-------------------------------------+ | 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. This scheme should be suitable for applications like smart-home management, body area networks, etc., where provisioning with the secret is feasible. PKI based authentication is too complex in terms of infrastructure, implementation and computation for such scenarios. The proposed scheme could be a more lightweight yet robust alternative to conventional DTLS with PSK. The advantage of the proposed scheme is demonstrated through experimental results presented in Section 4. This draft is an extension of the initial work presented in [I.D. core-coap-lite-auth]. 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 Bhattacharyya, et al. Expires October 17, 2015 [Page 4] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 -> | : 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.] ** 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 Bhattacharyya, et al. Expires October 17, 2015 [Page 5] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 (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 ----------------------- 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. Bhattacharyya, et al. Expires October 17, 2015 [Page 6] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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 +--------------+--------+------------------------------------------+ | 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 October 17, 2015 [Page 7] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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 October 17, 2015 [Page 8] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 {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 October 17, 2015 [Page 9] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 +-----------------+ +----------+ +--------------------------------+ |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. Table 3-5 tabulates the different results. Bhattacharyya, et al. Expires October 17, 2015 [Page 10] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 +----------+-------------+---------+ | 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 October 17, 2015 [Page 11] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 +----------+-------------+---------+ | 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 October 17, 2015 [Page 12] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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. * 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] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [I.D.core-coap-lite-auth] Bhattacharyya, et al. Expires October 17, 2015 [Page 13] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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.rescorla-sec-cons-05] Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on Security Considerations", draft-rescorla-sec-cons-05, April 2002 7.2. Informative References [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] Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., "Lightweight security scheme for vehicle tracking system using CoAP", ACM ASPI-Ubicomp Adjunct, 2013. Bhattacharyya, et al. Expires October 17, 2015 [Page 14] Internet-Draft draft-bhattacharyya-dice-less-on-coap-00 April 2015 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 October 17, 2015 [Page 15]