idnits 2.17.1 draft-bhattacharyya-core-coap-lite-auth-00.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 -- The document date (March 3, 2014) is 3705 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: 'I-D.hartke-core-codtls' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-seitz-core-sec-usecases' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'ASPI-Ubicomp' is defined on line 397, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-hartke-core-codtls (ref. 'I-D.hartke-core-codtls') ** Downref: Normative reference to an Informational draft: draft-seitz-core-sec-usecases (ref. 'I-D.draft-seitz-core-sec-usecases') ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE A. Bhattacharyya 2 Internet Draft S. Bandyopadhyay 3 Intended status: Standards track A. Ukil 4 Expires: September 2014 T. Bose 5 A. Pal 6 TATA CONSULTANCY SERVICES LTD. 7 March 3, 2014 9 Lightweight mutual authentication for CoAP (WIP) 10 draft-bhattacharyya-core-coap-lite-auth-00 12 Abstract 14 This draft presents a work-in-progress on a challenge-response based 15 lightweight authentication scheme to mutually authenticate CoAP 16 client and server for establishing a secure unicast communication 17 channel. The draft discusses the generic idea behind the proposed 18 authentication scheme, as well as presents its CoAP specific 19 adoption. The proposed scheme has low communication overhead and can 20 be a robust alternative against the usual DTLS based connection 21 initiation scheme with PSK. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet- 41 Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six 44 months and may be updated, replaced, or obsoleted by other documents 45 at any time. It is inappropriate to use Internet-Drafts as 46 reference material or to cite them other than as "work in progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html 54 This Internet-Draft will expire on September 3, 2014. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with 66 respect to this document. Code Components extracted from this 67 document must include Simplified BSD License text as described in 68 Section 4.e of the Trust Legal Provisions and are provided without 69 warranty as described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction ................................................ 2 74 2. The Algorithm ............................................... 3 75 2.1. Assumptions ............................................ 4 76 2.2. Threats considered ..................................... 4 77 2.3. Connection initiation and authentication ............... 4 78 2.3.1. Nonce generation .................................. 6 79 2.4. CoAP specific implementation ........................... 6 80 3. Session time-out and resumption ............................. 9 81 4. Integration with DTLS ....................................... 9 82 5. Security Considerations ..................................... 9 83 6. References ................................................. 10 84 6.1. Normative References .................................. 10 85 6.2. Informative References ................................ 10 87 1. Introduction 89 The Constrained Application Protocol (CoAP)[I-D.ietf-core-coap] 90 specification mandates the use of DTLS for secure connection 91 establishment between end-points. But DTLS implementation with full 92 public-key infrastructure is not a resource-optimal solution for 93 constrained M2M scenario. So CoAP proposes different configurations 94 of DTLS with minimal resource-consumption mode. But such modes do 95 not offer as robust authentication as the certificate based security 96 scheme using PKI. Pre-Shared-Key (PSK) is such a mode. 98 However, even in PSK mode, the communication overhead for key- 99 negotiation prior to connection establishment may prove costly in 100 certain constrained environments. In fact, by default, DTLS adds to 101 the connection overhead compared to the base protocol TLS. This is 102 caused due to cookie exchanges introduced to combat certain DoS 103 attacks as specified in Section 4.2.1 of [RFC6347]. [I-D.hartke- 104 core-codtls] touches upon different ways and means to optimize DTLS 105 for constrained environment. This includes the possibility of using 106 client puzzles to reduce the number of handshakes during the 107 connection initiation phase. 109 This draft presents a computationally simple yet robust challenge- 110 response scheme for mutual authentication along with key management 111 between end-points. The end-points share a pre-shared secret during 112 provisioning. The scheme completes the authentication in 4 handshake 113 messages where the message payloads do not exceed 256 bits. Thus the 114 scheme is low in communication overhead. 116 This scheme should be suitable for environments like smart-home 117 management, body area networks, etc., where the end-points form a 118 closed system and pre-sharing of secret is feasible. PKI based 119 authentication is too complex in terms of infrastructure, 120 implementation and computation for such scenarios. The proposed 121 scheme could be a lightweight yet robust alternative to conventional 122 DTLS with PSK. 124 The present draft explains the generic algorithm and proposes a CoAP 125 specific implementation of the same with the necessary adjustments 126 in the base protocol. 128 The proposed idea could also be leveraged to bring in modifications 129 in DTLS and make DTLS further lightweight yet robust. That work is 130 TBD. 132 2. The Algorithm 134 The proposed solution is symmetric key based security mechanism 135 where key management is integrated with authentication mechanism. 136 Following the suggested requirements in [I-D.draft-seitz-core-sec- 137 usecases] the proposed scheme allows mutual authentication between 138 the peers. 140 2.1. Assumptions 142 A secret is pre-shared between the communicating end-points. This 143 kind of provisioning phase should be common for implementations in 144 applications like smart-home management, body area networks, etc. It 145 is assumed, in agreement with 'the Internet threat model' discussed 146 in section 3 of [I.D.rescorla-sec-cons-05], that the end-devices are 147 tamper-safe so that the security primitives are not compromised. 149 2.2. Threats considered 151 Broader security threats like disclosure of sensitive information 152 and resource consumption attacks are considered. Thus the proposed 153 scheme considers threats like replay attack, DoS attack, meet-in- 154 the-middle attack, chosen-cipher-text attack. 156 2.3. Connection initiation and authentication 158 Algorithm-1 below describes the algorithm for mutual authentication 159 and connection initiation. 161 ----------------------------------------------------------------------- 162 Algorithm-1 163 ----------------------------------------------------------------------- 164 ** Prerequisite: 166 A 128 bit secret Yi is shared between Di (i-th sensor-device) and G 167 (server) offline at provisioning phase. 169 ** Step 1 - Connection initiation: 171 Di sends "HELLO, #Di" to G at the time of session initiation (#Di: 172 unique device ID). 174 ** Step 2 - Server challenge: 176 G responds as AES{Yi, (Yi XOR Ki | nonce1)}, where Ki is the 177 potential session key if the handshake is successful, 'nonce1' is 178 pseudo randomly generated nonce specific to one authentication 179 session. Both Ki and nonce1 is 128 bit each. Total message size is 180 256 bit. 182 [Optional: G may perform a table look-up to check if the #Di is 183 valid before challenging client. If #Di is not valid then the 184 handshake does not proceed further.] 186 ** Step 3 - Sensor response and challenge: 188 Di returns AES{Ki, (nonce1 XOR Yi | nonce2)}. Thus if Di is able to 189 decipher the challenge from G then it will have the right nonce1 190 which is embedded in the response. This completes the client side 191 authentication and key exchange. Also, to check the authenticity of 192 the server, Di challenges G with nonce2, where nonce2 is nonce 193 generated by the client. 195 ** Step 4 - Server response: 197 Server verifies nonce1 and responses to sensor by sending nonce2. 199 ** Result: 201 If nonce2 from G satisfies Di then the mutual authentication is 202 completed and the session key Ki is mutually agreed. 204 ----------------------------------------------------------------------- 206 Figure 1 illustrates the above steps. 208 Di(Client #i) G(Server) 209 | | 210 | | 211 +--------------------------------->| 212 | Hello, #Di | 213 | | 214 |<---------------------------------| 215 | AES{Yi, (Yi XOR Ki | nonce1)} | 216 | | 217 |--------------------------------->| 218 | AES{Ki, (nonce1 XOR Yi | nonce2)}| 219 | | 220 |<---------------------------------| 221 | AES{Yi, (nonce2 | Ki)} | 222 | | 224 Legends: #Di - ID of device number i, Yi - the pre-shared secret, Ki 225 - the session key, nonce1 - nonce generated by server, nonce2 - 226 nonce generated by client 228 Figure 1: Illustration of steps in Algorithm-1 230 2.3.1. Nonce generation 232 The 'nonce' is produced by a pseudo random number Ri appended with a 233 timer (counter) Ti. Ri is generated in pseudo-random way, and its 234 inclusion with Ti assures that replay attack is improbable. The non- 235 reproducibility nature of the constructed nonce is governed by Ti 236 and the non-predictable and collision resistance property is 237 governed by Ri. 239 2.4. CoAP specific implementation 241 This section describes how the proposed scheme can be integrated 242 with CoAP. The inherent reliable delivery helps easy implementation 243 of the proposed scheme against packet loss. 245 Two options are introduced for POST method to be used for 246 authentication as described in Table 1 and 2. 248 +-----+---+---+---+---+--------------+--------+--------+---------+ 249 | No. | C | U | N | R | Name | Format | Length | Default | 250 +-----+---+---+---+---+--------------+--------+--------+---------+ 251 | TBD | X | X | - | | Auth | empty | 0 | (none) | 252 +-----+---+---+---+---+--------------+--------+--------+---------+ 253 | TBD | X | X | - | | Auth-Msg-Type| uint | 1 | (none) | 254 +-----+---+---+---+---+--------------+--------+--------+---------+ 256 Table 1: Option Properties 258 +--------------+--------+------------------------------------------+ 259 | Name | Method | Description | 260 +--------------+--------+------------------------------------------+ 261 | Auth | |If present, indicates that the POST | 262 | | |request carries authentication payload. | 263 +--------------+ +------------------------------------------+ 264 | | |Always to be used with 'Auth'. Value of | 265 | | |this. | 266 | | POST |option indicates the type of | 267 | | |authentication request. Value in this | 268 | Auth-Msg-Type| |field determines the response by sever | 269 | | |against POST with 'Auth'. It can assume | 270 | | |two values: | 271 | | |0 (auth-init) -> Authentication initiation| 272 | | |with hello from client, | 273 | | |1 -> response-against-challenge. | 274 +--------------+--------+------------------------------------------+ 275 Table 2: Description of the options. 277 Figure 2 illustrates the handshake. 279 Client #i Server 280 | | 281 | | 282 +--------------------------------------------->| 283 | POST: CON; MsgID = n; Token = m; | 284 | URI=/.well-known/authorize; | 285 | AUTH = true; | 286 | AUTH-MSG-TYPE = 0; | 287 | Payload= | 288 | | 289 |<---------------------------------------------| 290 | ACK; MsgID = n; Token = m; | 291 | Payload = AES{Yi, (Yi XOR Ki | nonce1)}; | 292 | Response = 2.01 CREATED /session/ | 293 | (if ID not-found then 4.01 UNAUTHORIZED) | 294 | | 295 |--------------------------------------------->| 296 | POST: CON; MsgID = n+1; Token = m; | 297 | AUTH = true; | 298 | AUTH-MSG-TYPE = 1; | 299 | URI= /session/ | 300 | Payload = AES{Ki, (nonce1 XOR Yi | nonce2)}; | 301 | | 302 |<---------------------------------------------| 303 | ACK; MsgID = n+1; Token = m; | 304 | Payload = AES{Yi, (nonce2 | Ki)}; | 305 | Response = 2.04 CHANGED | 306 | (Client authenticated) | 307 | (if received 'nonce1' does not match with | 308 | server copy then 4.01 UNAUTHORIZED) | 309 | | 311 Figure 2. Proposed CoAP specific implementation of Algorithm-1. 313 The 4-way handshake is described below: 315 1. At initiation, the client sends a POST message in CON mode to a 316 server URI "/.well-known/authorize". The 'Auth' option is set to 317 true. The 'Auth-Msg-Type' set as 'auth_init', and 'device 318 identifier' in the payload. '\authorize' is the resource at the 319 server for initiating authorization activity. 321 2. The combination of Auth = True and Auth-Msg-Type = 'auth-init' 322 indicates a session initiation to the server. The server derives 323 device identifier from the received payload and determines pre- 324 shared secret associated with that device-identifier. The server 325 then generates 'nonce1' (server-nonce) and a Key (K). Server forms 326 an encrypted payload comprising nonce1 and K using the shared secret 327 (Y). 329 3. Server responds back the client with a response code indicating 330 creation of a new resource. The URI in the response indicates a 331 temporary session ID. In case of an invalid device identifier server 332 sends a response code 'Unauthorized'. 334 4. The client decrypts response received from server and obtains 335 'nonce1' and 'K'. It generates nonce2 (client-nonce) and then 336 creates encrypted payload using key 'K'. It sends this payload using 337 a POST message with option field 'Auth' and 'Auth-Msg-Type' set to 338 'response-against-server-challenge'. The same token value as in 339 initiating POST request is kept. 341 5. Server decrypts payload of the POST message with above mentioned 342 optional values in header using 'K' and checks the received 343 'nonce1'. Server sends a response with response code 'Changed' to 344 indicate that a change in the resource was authenticated if 'nonce1' 345 is identical with its previous value (generated in step 2), 346 otherwise sends 'Unauthorized'. 348 3. Session time-out and resumption 350 Session time-out is proposed to enable re-negotiation of the key. 351 This would help combat the chosen-cipher-text attack. The detail 352 handshake is TBD. 354 4. Integration with DTLS 356 It is envisioned that conventional DTLS can be modified to integrate 357 a scheme like this to develop a robust yet light-weight 358 authentication mechanism within the DTLS framework. Work on this is 359 currently in progress. Details are TBD. 361 5. Security Considerations 363 The draft itself deals with security. The security considerations 364 are described Section 2 of this document. 366 6. References 368 6.1. Normative References 370 [I-D.ietf-core-coap] 372 Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application 373 Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013 375 [I-D.hartke-core-codtls] 377 Hartke, K.,"Datagram Transport Layer Security in Constrained 378 Environments", draft-hartke-core-codtls-02, July 16, 2012 380 [I-D.draft-seitz-core-sec-usecases] 382 Seitz, L., Gerdes, S. and Selander, G.," Use cases for CoRE 383 security", draft-seitz-core-sec-usecases-00, September 16, 2013 385 [RFC6347] 387 Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security 388 Version 1.2", RFC 6347, January 2012. 390 [I.D.rescorla-sec-cons-05] 392 Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on 393 Security Considerations", draft-rescorla-sec-cons-05, April 2002 395 6.2. Informative References 397 [ASPI-Ubicomp] 399 Ukil, A., Bandyopadhyay, S., Bhattacharyya, A. and Pal, A., 400 "Lightweight security scheme for vehicle tracking system using 401 CoAP," ACM ASPI-Ubicomp Adjunct, 2013. 403 Authors' Addresses 405 Abhijan Bhattacharyya 406 Tata Consultancy Services Ltd. 407 Kolkata, India 409 Email: abhijan.bhattacharyya@tcs.com 411 Soma Bandyopadhyay 412 Tata Consultancy Services Ltd. 413 Kolkata, India 415 Email: soma.bandyopadhyay@tcs.com 417 Arijit Ukil 418 Tata Consultancy Services Ltd. 419 Kolkata, India 421 Email: arijit.ukil@tcs.com 423 Tulika Bose 424 Tata Consultancy Services Ltd. 425 Kolkata, India 427 Email: tulika.bose@tcs.com 429 Arpan Pal 430 Tata Consultancy Services Ltd. 431 Kolkata, India 433 Email: arpan.pal@tcs.com