idnits 2.17.1 draft-bhattacharyya-dice-less-on-coap-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 314 has weird spacing: '...nerated by th...' -- The document date (March 3, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'PITSAC-AINA' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'PERCOM-Workshop' is defined on line 684, but no explicit reference was found in the text == Unused Reference: 'ASPI-Ubicomp' is defined on line 690, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 dice A. Bhattacharyya 2 Internet Draft T. Bose 3 Intended status: Standards Track A. Ukil 4 Expires: September 2018 S. Bandyopadhyay 5 A. Pal 6 TATA CONSULTANCY SERVICES LTD. 7 March 3, 2018 9 Lightweight Establishment of Secure Session (LESS) on CoAP 10 draft-bhattacharyya-dice-less-on-coap-01 12 Abstract 14 Secure yet lightweight protocol for communication over the Internet 15 for constrained node networks (CNN) is a pertinent problem. 16 Constrained Application Layer Protocol (CoAP) mandates the use of 17 Datagram Transport Layer Security (DTLS) for a secure transaction 18 over CoAP. But DTLS is not a candidate technology for CNNs by 19 design. The DTLS handshake overhead to establish the credentials for 20 a session between two end-points in a CNN may not be resource 21 efficient. There are ongoing efforts to secure one-time exchanges by 22 ensuring object security at the application layer. But a composite 23 standardized mechanism for resource-efficient end-to-end security 24 credential establishment is much needed to cater both one-time 25 exchanges as well as exchanges over a session. DTLS is essentially a 26 combination of two operations: (1) the session protocol to establish 27 the credentials (and this is the resource heavy part), (2) the 28 record protocol to protect the information (this is the 29 cryptographic part). This draft proposes to distribute the security 30 responsibilities such that the session establishment happens in the 31 application layer, leveraging the lightweight semantics of CoAP, and 32 the record layer encryption happens by reusing the existing DTLS 33 record-layer protocol. This way the proposed mechanism enables a 34 resource-efficient session establishment mechanism besides reusing 35 the existing DTLS encryption. Assuming a Pre-Shared Key (PSK) 36 environment, this draft proposes an embedding of handshake for 37 resource efficient end-to-end session establishment into CoAP. The 38 session establishment procedure produces the necessary and 39 sufficient inputs for seamless operation of the DTLS record-layer to 40 secure the channel. Also, this mechanism ensures a direct security 41 association between the end-applications for systems using 42 middleboxes like proxies and/or gateways which may not be always 43 trusted. The proposed approach provides a mechanism to securely 44 traverse through such middleboxes through an end-to-end trusted 45 channel. 47 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF), its areas, and its working groups. Note that 54 other groups may also distribute working documents as Internet- 55 Drafts. 57 Internet-Drafts are draft documents valid for a maximum of six 58 months and may be updated, replaced, or obsoleted by other documents 59 at any time. It is inappropriate to use Internet-Drafts as 60 reference material or to cite them other than as "work in progress." 62 Internet-Drafts are working documents of the Internet Engineering 63 Task Force (IETF), its areas, and its working groups. Note that 64 other groups may also distribute working documents as Internet- 65 Drafts. 67 Internet-Drafts are draft documents valid for a maximum of six 68 months and may be updated, replaced, or obsoleted by other documents 69 at any time. It is inappropriate to use Internet-Drafts as 70 reference material or to cite them other than as "work in progress." 72 The list of current Internet-Drafts can be accessed at 73 http://www.ietf.org/ietf/1id-abstracts.txt 75 The list of Internet-Draft Shadow Directories can be accessed at 76 http://www.ietf.org/shadow.html 78 This Internet-Draft will expire on September 3, 2018. 80 Copyright Notice 82 Copyright (c) 2018 IETF Trust and the persons identified as the 83 document authors. All rights reserved. 85 This document is subject to BCP 78 and the IETF Trust's Legal 86 Provisions Relating to IETF Documents 87 (http://trustee.ietf.org/license-info) in effect on the date of 88 publication of this document. Please review these documents 89 carefully, as they describe your rights and restrictions with 90 respect to this document. Code Components extracted from this 91 document must include Simplified BSD License text as described in 92 Section 4.e of the Trust Legal Provisions and are provided without 93 warranty as described in the Simplified BSD License. 95 Table of Contents 97 1. Introduction...................................................3 98 1.1. Application scenario......................................3 99 1.1.1. Session based secure communication over CNN..........4 100 1.2. State of standardization for securing CoAP................4 101 1.3. Proposed approach.........................................5 102 2. The Algorithm..................................................7 103 2.1. Implementation on CoAP....................................9 104 3. Enabling channel security: Re-using DTLS record encryption....11 105 4. Experimental Results..........................................13 106 5. Session time-out and resumption...............................15 107 6. Security Considerations.......................................16 108 7. References....................................................16 109 7.1. Normative References.....................................16 110 7.2. Informative References...................................17 112 1. Introduction 114 Secure communication between two end-points in a CNN typical for 115 Internet of Things (IoT)/ Machine to Machine (M2M) communication 116 must be resource-efficient. The resource-efficiency must be ensured 117 while establishing the security credentials. The process should be 118 acceptable not only for communications like a single-shot small 119 sensor data update, but also for exchanges which may happen over a 120 session. 122 Furthermore, when the end-to-end channel has to go through 123 middleboxes, like proxies or gateways, there may be need to 124 establish a direct security association between the end-points and 125 the middleboxes may not always be trusted. This is also useful if 126 one of the end-point application layer connects over a non-IP link 127 via a gateway that translates the connection to an IP network. 129 The next subsections describe typical application scenario, current 130 status of standardization on this aspect around CoAP [RFC7252] and 131 the proposed approach. 133 1.1. Application scenario 135 [I.D.draft-friel-tls-atls] describes the scenarios which would need 136 an end-to-end direct security association over a secure channel 137 through middlebox. 139 Next we describe exemplary application which may need to establish a 140 secure channel for session based exchange over a CNN. 142 1.1.1. Session based secure communication over CNN 144 Scenario 1: 146 Vehicles post their instant locations to the smart traffic 147 application server of the concerned authority in an intelligent 148 traffic system (ITS) for smart city applications. Locations may be 149 updated through a GPS sensor on vehicle which connects to the 150 Internet over cellular network. This requires a resource efficient, 151 low-latency secure session establishment between the sensor on 152 vehicle and the end-server to ensure a secure end-to-end channel all 153 through the journey of each individual vehicle. Session time-out and 154 refreshment of security credentials is also needed to prevent 155 passive attacks through session activity analysis. The vehicles 156 would have to move through different terrains with highly 157 fluctuating channel conditions. The session establishment procedure 158 must be capable of establishing a successful secure session even 159 under lossy condition. 161 Scenario 2: 163 Another example could be real-time update of sensitive and critical 164 health parameters of a patient being moved to a hospital in an 165 emergency vehicle. The health information is communicated by sensor 166 devices which connects via an onboard gateway. The sensor 167 establishes a direct security association with the specialist doctor 168 portal at the hospital. Continuous health parameters are transferred 169 over a secure session through a secure channel. The resource 170 efficiency requirements described in the above scenario is also 171 valid in this case. This kind of scenario will also need to have a 172 robust yet resource-efficient mechanism for establishing and 173 refreshing session security credentials under intermittent channel 174 conditions. 176 1.2. State of standardization for securing CoAP 178 The Constrained Application Protocol (CoAP)[RFC7252] specification 179 mandates the use of DTLS for secure connection establishment between 180 end-points. Sine full PKI based systems with certificate exchange, 181 etc. prove too resource heavy, CoAP proposes different flavours of 182 DTLS. DTLS with Pre-Shared Key (PSK) is the option with minimum 183 resource requirement. However, even in PSK mode, the communication 184 overhead for key-negotiation prior to connection establishment may 185 prove costly in certain constrained environments. In fact, by 186 default, DTLS adds to the connection overhead compared to the base 187 protocol TLS. This is caused due to cookie exchanges introduced to 188 combat certain DoS attacks as specified in Section 4.2.1 of 190 [RFC6347]. Also, individual DTLS messages may lead to uncontrolled 191 fragmentation resulting into degraded network performance. 193 There are ongoing efforts [I.D. draft-ietf-core-object-security] to 194 secure individual CoAP payload using CBOR Object Signing and 195 Encryption (COSE) [RFC8152]. This approach also takes care of 196 creating end-to-end security association through middleboxes. But 197 this is not designed for a session-based communication which might 198 need protection of the complete application layer message over an 199 end-to-end secure channel without terminating the security 200 association at the transport/ application-layer middleboxes. 202 1.3. Proposed approach 204 The draft proposes a cross-layer approach to distribute the 205 responsibilities for secure channel establishment in the following 206 manner: 208 i) CoAP, through its RESTful request/response semantics, takes care 209 of mutual authentication of the end-points and establishment of the 210 session security parameters (like the session keys). 212 ii) Once the session is established, the transports at the end- 213 points reuse the DTLS record encryption mechanism to ensure 214 standardized channel security of the full CoAP messages throughout 215 the session. 217 Figure 1 illustrates the responsibility of different layers in the 218 proposed complete security suit. 220 +-------------------------------------+ 221 | CoAP (Establishes secure session) | 222 +-------------------------------------+ 223 || 224 \/ 225 +-------------------------------------+ 226 | Interface | 227 | (Arranges the session parameters) | 228 +-------------------------------------+ 229 || 230 \/ 231 +-------------------------------------+ 232 | Secure Transport (Reuses DTLS | 233 | record encryption using the session | 234 | parameters for channel security) | 235 +-------------------------------------+ 237 Figure 1: Illustrating the across-the-layer distribution of 238 responsibilities. 240 As an initial effort, point (i) above is achieved by assuming that 241 the end-points are pre-provisioned with a pre-shared secret. An 242 exemplary computationally simple yet robust challenge-response 243 scheme for establishing a secure session between two endpoints is 244 proposed. The secure session establishment process comprises of 245 mutual authentication of the endpoints and sharing the session-keys 246 between the endpoints. (It is also to be observed that DTLS-PSK only 247 allows server to authenticate the client. The reverse does not 248 happen.) The scheme completes the session establishment in just 4 249 handshake messages. The full handshake can be modelled as just 2 250 pairs of CoAP request/response. The maximum possible application 251 layer message size during the handshake is kept low to avoid 252 unwanted fragmentation at the lower layers for most of the cases. 253 Thus the scheme is low in communication overhead. So, this draft 254 enables CoAP with an inherent mechanism of secure session 255 establishment. While the established credentials enables the system 256 to reuse DTLS record-layer, it may well be used for only 'object- 257 security' over CoAP. The later will be useful in scenarios where 258 CoAP is deployed over a transport which does not have DTLS-like 259 security. 261 The advantage of the proposed scheme is demonstrated through 262 experimental results presented in Section 4. 264 This draft is an extension of the initial work presented in [I.D. 265 core-coap-lite-auth]. 267 The basic approach proposed in this draft may be extended to more 268 complex security association beyond PSK. 270 2. The Algorithm 272 Algorithm-1 below describes the generic challenge-response based 273 algorithm for secure session establishment. Figure 2 illustrates the 274 steps of Algorithm-1. 276 Interpretation of the expressions used in Algorithm-1 are explained 277 below: 279 -> AES{expr}_Y : AES_128_CCM_8 encryption of 'expr' with key Y 281 -> | : Concatenation operation 283 -> {0,1}^N : A binary string of N bits 285 -> vect[N1:N2] : Accessing bit position N1 to N2 of bit vector 286 'vect'. 288 ----------------------------------------------------------------------- 289 Algorithm-1 290 ----------------------------------------------------------------------- 291 **Step 0: Pre-sharing secret (prerequisite)- 293 A 128 bit secret (Y) is shared between client C_i and server S 294 offline at provisioning phase. 296 ** Step 1 - Session initiation: 298 C_i initiates the session by sending a HELLO to S. The HELLO 299 comprises of #Ci and 'hello_rand'. (#Ci is the unique client ID and 300 hello_rand is a random number of 12 bytes.) 302 ** Step 2 - Server challenge: 304 S responds as: AES {(ext_hello_rand XOR (k_c | server_rand))}_Y 305 (Here, k_c = {0,1}^128 is the client-write key, server_rand= {0,1 306 }^96; ext_hello_rand = hello_rand | hello_rand[0:31]). 308 [Optional: S may perform a table look-up to check if the #Ci is 309 valid before challenging client. If #Ci is not valid then the 310 handshake does not proceed further.] 311 ** Step 3 - Client response and challenge: 313 Ci returns: AES{(server_rand | client_rand)}_k_c 314 (Here, client_rand = {0,1}^96 is a random number generated by the 315 client). 317 Thus if Ci is able to decipher the challenge from S in step 2 then 318 it will have the right 'k_c' and 'server_rand' which is embedded in 319 the response. This completes the client side key exchange. Then, Ci 320 responds as well as challenges S with random number 'client_rand' 321 encrypted with the client-write key k_c. 323 ** Step 4 - Server response: 325 Server verifies server_rand from client with its own copy and 326 returns: AES {(ext_server_rand XOR (k_s | client_rand))}_Y 327 (Here, ext_server_rand = server_rand | server_rand[0:31] and k_s = 328 {0,1}^128 is the server-write key). 330 ** Result: 332 If server_rand from S satisfies Ci then the mutual authentication is 333 completed and Ci gets the server-write key k_s with which the server 334 messages are to be deciphered for a given session. Thus, after the 335 handshake is over, both the end-points have mutually agreed on the 336 server-write and client-write key pair {k_s, k_c} for a given 337 session. 339 Note: The AES encryption is implemented as AES_128_CCM_8. CCM mode 340 would need 12 bit nonce for each encryption and an additional data. 341 'hello_rand', 'server_rand' and 'client_rand' serves as the required 342 nonce values in steps 2, 3 and 4 respectively. The 'additional data' 343 can be the header for each message of the application layer protocol 344 (ex. CoAP) on which the scheme is adapted. 346 ---------------------------- END of Algorithm 1 ----------------------- 347 Ci(Client #i) S(Server) 348 | | 349 | | 350 +---------------------------------------------------->| 351 | Hello, #Ci, hello_rand | 352 | | 353 |<----------------------------------------------------| 354 | AES{(ext_hello_rand XOR k_c) | server_rand}_Y | 355 | | 356 |---------------------------------------------------->| 357 | AES{server_rand | client_rand}_k_c | 358 | | 359 |<----------------------------------------------------| 360 | AES{(ext_server_rand XOR k_s) | client_rand}_Y | 361 | | 363 Figure 2: Illustration of steps in Algorithm-1 365 2.1. Implementation on CoAP 367 This section describes how the proposed scheme can be implemented on 368 CoAP. The inherent reliable delivery feature of CoAP helps easy 369 implementation of the proposed scheme against packet loss. 371 Two options are introduced for POST method to be used for 372 authentication as described in Table 1 and 2. 374 +-----+---+---+---+---+--------------+--------+--------+---------+ 375 | No. | C | U | N | R | Name | Format | Length | Default | 376 +-----+---+---+---+---+--------------+--------+--------+---------+ 377 | TBD | X | X | - | | Auth | empty | 0 | (none) | 378 +-----+---+---+---+---+--------------+--------+--------+---------+ 379 | TBD | X | X | - | | Auth-Msg-Type| uint | 1 | (none) | 380 +-----+---+---+---+---+--------------+--------+--------+---------+ 382 Table 1: Option Properties 384 +--------------+--------+------------------------------------------+ 385 | Name | Method | Description | 386 +--------------+--------+------------------------------------------+ 387 | Auth | |If present, indicates that the POST | 388 | | |request carries authentication payload. | 389 +--------------+ +------------------------------------------+ 390 | | |Always to be used with 'Auth'. Value of | 391 | | POST |the option indicates the type of | 392 | | |authentication request. Value in this | 393 | Auth-Msg-Type| |field determines the response by sever | 394 | | |against a POST request with 'Auth'. It can| 395 | | |assume two values: | 396 | | |0 (auth-init) -> Authentication initiation| 397 | | |with hello from client, | 398 | | |1 -> response-against-challenge. | 399 +--------------+--------+------------------------------------------+ 400 Table 2: Description of the options. 402 Figure 3 illustrates the handshake over CoAP. 404 Client #i Server 405 | | 406 | | 407 +--------------------------------------------------------------->| 408 | POST: CON; MsgID = n; Token = m; | 409 | URI=/session; | 410 | AUTH = true; | 411 | AUTH-MSG-TYPE = 0; | 412 | Payload= , hello_rand | 413 | | 414 |<---------------------------------------------------------------| 415 | ACK; MsgID = n; Token = m; | 416 | Payload = AES{(ext_hello_rand XOR k_c) | server_rand}_Y; | 417 | Response = 2.01 CREATED /session/ | 418 | (if ID not-found then 4.01 UNAUTHORIZED) | 419 | | 420 |--------------------------------------------------------------->| 421 | POST: CON; MsgID = n+1; Token = m; | 422 | AUTH = true; | 423 | AUTH-MSG-TYPE = 1; | 424 | URI= /session/ | 425 | Payload = AES{server_rand | client_rand}_k_c | 426 | | 427 |<---------------------------------------------------------------| 428 | ACK; MsgID = n+1; Token = m; | 429 | Payload = AES{(ext_server_rand XOR k_s) | client_rand}_Y | 430 | Response = 2.04 CHANGED | 431 | (Client authenticated) | 432 | (if received server_rand does not match with | 433 | server copy then 4.01 UNAUTHORIZED) | 434 | | 436 Figure 3: Proposed CoAP specific implementation of Algorithm-1. 438 3. Enabling channel security: Re-using DTLS record encryption 440 At the end of the above described session establishment process both 441 client and server has the necessary key pair {k_s, k_c}. This might 442 suffice for providing 'object security'. 444 However, it may be possible to provide a solution by re-using the 445 per-session record-encryption mechanism as deployed in DTLS. To 446 achieve this we need to fill-up the DTLS session parameter structure 447 for each session prior to record encryption. 449 To do this we essentially need the encryption tuple: 451 {server-write key, client-write key, server_IV, client_IV}. 453 We already have the first two parameters as {k_s, k_c}. Computation 454 of server_IV and client_IV has to happen at both the endpoints. 455 There can be several complex mathematical functions to do this 456 computation. Figure 4 illustrates a very naive way. 458 <-----------------------12 Bytes----------------------> 459 +-----------------------------------------------------+ 460 | client_rand | 461 +-----------------------------------------------------+ 463 XOR 465 +-----------------------------------------------------+ 466 | server_rand | 467 +-----------------------------------------------------+ 469 || 470 \/ 472 <-----------------------12 Bytes----------------------> 473 +-----------------------------------------------------+ 474 | <--- 4 Bytes ---> | <--- 4 Bytes ---> | | 475 +-----------------------------------------------------+ 476 /\ /\ 477 || || 478 client_IV server_IV 480 Figure 4: Calculating client_IV and server_IV. 482 Figure 5 illustrates how the session parameters for the proposed 483 scheme can directly map to the DTLS session parameters structure 484 thus enabling the record encryption process for each session. 486 +-----------------+ +----------+ +--------------------------------+ 487 |Session ID | |Pre-shared| |{k_s, k_c, server_IV, client_IV}| 488 |(Shared by server| |secret (Y)| +--------------------------------+ 489 | as part of a | +----------+ || || 490 | temp URI path) | | | || || 491 +-----------------+ | | || || 492 || | +-------------+ || || 493 || +--------------+| || || 494 \/ \/ \/ \/ 495 +-----+------+---------+-------------+------+-----+-----+----------+ 496 |Sess.|Peer |Compress.|Cipher |Master|Read |Write|Seq. | 497 |ID |Cert. |Method = | suit = |secret|state|state|No. | 498 | |= NULL|NULL |AES_128_CCM_8| | | |(implicit)| 499 +-----+------+---------+-------------+------+-----+-----+----------+ 501 Figure 5: Mapping of different session parameters to the DTLS 502 session parameter structure for PSK mode. 504 Once the session parameter structure is filled, conventional 505 symmetric DTLS-PSK record encryption method can be used to provide 506 channel encryption to the full application layer message (data + 507 header). 509 Thus the above discussions, fundamentally, propose a cross layer 510 approach (Figure 1) - secure session established in a lightweight 511 manner at the application layer (CoAP) and session wise channel 512 encryption is performed at the transport layer using DTLS record 513 encryption method. 515 4. Experimental Results 517 Experiments were performed in an emulated WAN environment which 518 allows to control the network parameters. The session establishment 519 process was run for about a thousand times in a loop for both 520 standard Californium DTLS-PSK implementation and the proposed 521 solution. Performance measurement was carried out in terms of the 522 average number of bytes over the media and average latency per 523 session establishment under different packet errors. A third 524 parameter was the percentage of successful session establishment 525 under different packet errors. End-to-end bandwidth was set at a 526 minimal 9.6 Kbps.Table 3-5 tabulates the different results. 528 +----------+-------------+---------+ 529 | Pkt.Loss | LESS on CoAP| DTSL-PSK| 530 +----------+-------------+---------+ 531 | 0% | 0.4018s | 0.23s | 532 +----------+-------------+---------+ 533 | 5% | 2.20s | 26.44s | 534 +----------+-------------+---------+ 535 | 10% | 6.00s | 29.85s | 536 +----------+-------------+---------+ 537 | 15% | 13.36s | 47.29s | 538 +----------+-------------+---------+ 539 | 20% | 26.864s | 76.37s | 540 +----------+-------------+---------+ 542 Table 3: Performance comparison in terms of average latency per 543 session establishment process. 545 +----------+-------------+---------+ 546 | Pkt.Loss | LESS on CoAP| DTSL-PSK| 547 +----------+-------------+---------+ 548 | 0% | 435.98B | 853B | 549 +----------+-------------+---------+ 550 | 5% | 453.05B | 962.55B | 551 +----------+-------------+---------+ 552 | 10% | 476.17B | 1030.02B| 553 +----------+-------------+---------+ 554 | 15% | 523.34B | 1094.71B| 555 +----------+-------------+---------+ 556 | 20% | 566.1386B| 1219.63B| 557 +----------+-------------+---------+ 559 Table 4: Performance comparison in terms of average number of bytes 560 exchanged over the physical media per session establishment process. 562 +----------+-------------+---------+ 563 | Pkt.Loss | LESS on CoAP| DTSL-PSK| 564 +----------+-------------+---------+ 565 | 0% | 100% | 100% | 566 +----------+-------------+---------+ 567 | 5% | 100% | 0.92% | 568 +----------+-------------+---------+ 569 | 10% | 100% | 0.91% | 570 +----------+-------------+---------+ 571 | 15% | 100% | 0.87% | 572 +----------+-------------+---------+ 573 | 20% | 100% | 0.78% | 574 +----------+-------------+---------+ 576 Table 5: Rate of successful session establishment 578 The above results establish that the proposed method has significant 579 improvement in terms of different performance metrics. One point to 580 be noted here is, the latency with 0% packet loss (Table 3) is 581 marginally higher in case of LESS on CoAP. This is attributed to the 582 fact that the latency measurement incorporates the computation time 583 at the endpoints. Since, LESS deploys encryption-decryption routines 584 during session establishment unlike DTLS-PSK so we see a marginal 585 higher latency under ideal condition. However, as the channel 586 worsens that marginal computational time loses any significance. 588 Another important point to be observed is the rate of unsuccessful 589 session establishment attempts as displayed in Table 5. It has been 590 observed that with increasing packet loss final 'flights' in DTLS 591 tend to fail the integrity check. 593 5. Session time-out and resumption 595 Session time-out is proposed to enable re-negotiation of the key. 596 This would help combat the chosen-cipher-text attack. The detail 597 handshake is TBD. It is to be mentioned that when the system deploys 598 the full proposed channel security, the control needs to go back 599 from transport to application. A possible way to identify a session 600 timeout response from the server and switching back the control to 601 application layer may be through handling the DTLS alarm messages in 602 a clever way (or, proposing a new DTLS alarm message for this 603 purpose). 605 6. Security Considerations 607 The draft itself deals with lightweight security. This section 608 briefly mentions the resilience of the proposed mechanism against 609 some common attacks. 611 * Passive attack due to traffic analysis: 613 Frequently changing the session parameters may help prevent this 614 kind of attack. Also, the session keys are obfuscated within the 615 payloads. So, even if one gets hold of Y, getting the session key 616 would need 2^256 or approximately 1.16*10^77 attempts. 618 * Denial of Service (DoS): 620 DoS launched by an attacker can have two fold effects: 1. Consuming 621 resources on the server by transmitting a series of session 622 initiation requests. 2. Using the server as an amplifier by issuing 623 session initiation requests with forged source leading to message 624 flooding. 626 The proposed challenge/response mechanism takes care of both of the 627 attacks. Any such attack should be ineffective just after the server 628 challenge. 630 However, deliberate too many simultaneous invalid attempts to 631 establish a session may jeopardise the server. 633 * Replay protection: 635 The DTLS record encryption has inherent protection against replay 636 attacks. Thus the proposed scheme leverages that capability by 637 reusing the DTLS record encryption for full channel security. 639 7. References 641 7.1. Normative References 643 [RFC7252] 645 Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application 646 Protocol (CoAP)", RFC 7252, June, 2014 648 [RFC6347] 649 Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security 650 Version 1.2", RFC 6347, January 2012. 652 [I.D.draft-friel-tls-atls] 654 Friel, O., Barnes, R., Pritikin, M., Tschofenig, H. and Baugher, M., 655 "Application-Layer TLS (ATLS)", draft-friel-tls-atls-00, January 656 2018. 658 7.2. Informative References 660 [I.D.core-coap-lite-auth] 662 Bhattacharyya, A., Bandyopadhyay, S., Ukil, A., Bose, T. and Pal, 663 A.," Lightweight mutual authentication for CoAP (WIP)", draft- 664 bhattacharyya-core-coap-lite-auth-00, March 3, 2014 666 [I.D. draft-ietf-core-object-security] 668 Salender, G., Mattsson, J., Palombini, F. and Seitz, L.," Object 669 Security for Constrained RESTful Environments (OSCORE)", draft-ietf- 670 core-object-security-08, January 22, 2018. 672 [RFC8152] 674 Schaad, J., "CBOR Object Signing and Encryption (COSE)", 675 RFC 8152, DOI 10.17487/RFC8152, July 2017, 676 . 678 [PITSAC-AINA] 680 Bhattacharyya, A., Bose, T., Bandyopadhyay, S., Ukil, A. and Pal, 681 A., " LESS: Lightweight Establishment of Secure Session", PITSaC(in 682 conjunction with AINA), 2015. 684 [PERCOM-Workshop] 686 Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., " Auth- 687 Lite: Lightweight M2M Authentication reinforcing DTLS for CoAP", 688 IEEE PERCOM Workshops, 2014. 690 [ASPI-Ubicomp] 691 Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., 692 "Lightweight security scheme for vehicle tracking system using 693 CoAP", ACM ASPI-Ubicomp Adjunct, 2013. 695 [I.D.rescorla-sec-cons-05] 697 Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on 698 Security Considerations", draft-rescorla-sec-cons-05, April 2002 700 Authors' Addresses 702 Abhijan Bhattacharyya 703 Tata Consultancy Services Ltd. 704 Kolkata, India 706 Email: abhijan.bhattacharyya@tcs.com 708 Soma Bandyopadhyay 709 Tata Consultancy Services Ltd. 710 Kolkata, India 712 Email: soma.bandyopadhyay@tcs.com 714 Arijit Ukil 715 Tata Consultancy Services Ltd. 716 Kolkata, India 718 Email: arijit.ukil@tcs.com 720 Tulika Bose 721 Tata Consultancy Services Ltd. 722 Kolkata, India 724 Email: tulika.bose@tcs.com 726 Arpan Pal 727 Tata Consultancy Services Ltd. 728 Kolkata, India 730 Email: arpan.pal@tcs.com