Internet DRAFT - draft-bhattacharyya-dice-less-on-coap
draft-bhattacharyya-dice-less-on-coap
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]
