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

Versions: 00 01

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= <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 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]


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