CoRE A. Bhattacharyya Internet Draft S. Bandyopadhyay Intended status: Standards track A. Ukil Expires: September 2014 T. Bose A. Pal TATA CONSULTANCY SERVICES LTD. March 3, 2014 Lightweight mutual authentication for CoAP (WIP) draft-bhattacharyya-core-coap-lite-auth-00 Abstract This draft presents a work-in-progress on a challenge-response based lightweight authentication scheme to mutually authenticate CoAP client and server for establishing a secure unicast communication channel. The draft discusses the generic idea behind the proposed authentication scheme, as well as presents its CoAP specific adoption. The proposed scheme has low communication overhead and can be a robust alternative against the usual DTLS based connection initiation scheme with PSK. 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 Bhattacharyya, et al. Expires September 3, 2014 [Page 1] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 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, 2014. Copyright Notice Copyright (c) 2014 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 ................................................ 2 2. The Algorithm ............................................... 3 2.1. Assumptions ............................................ 4 2.2. Threats considered ..................................... 4 2.3. Connection initiation and authentication ............... 4 2.3.1. Nonce generation .................................. 6 2.4. CoAP specific implementation ........................... 6 3. Session time-out and resumption ............................. 9 4. Integration with DTLS ....................................... 9 5. Security Considerations ..................................... 9 6. References ................................................. 10 6.1. Normative References .................................. 10 6.2. Informative References ................................ 10 1. Introduction The Constrained Application Protocol (CoAP)[I-D.ietf-core-coap] specification mandates the use of DTLS for secure connection Bhattacharyya, et al. Expires September 3, 2014 [Page 2] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 establishment between end-points. But DTLS implementation with full public-key infrastructure is not a resource-optimal solution for constrained M2M scenario. So CoAP proposes different configurations of DTLS with minimal resource-consumption mode. But such modes do not offer as robust authentication as the certificate based security scheme using PKI. Pre-Shared-Key (PSK) is such a mode. 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]. [I-D.hartke- core-codtls] touches upon different ways and means to optimize DTLS for constrained environment. This includes the possibility of using client puzzles to reduce the number of handshakes during the connection initiation phase. This draft presents a computationally simple yet robust challenge- response scheme for mutual authentication along with key management between end-points. The end-points share a pre-shared secret during provisioning. The scheme completes the authentication in 4 handshake messages where the message payloads do not exceed 256 bits. Thus the scheme is low in communication overhead. This scheme should be suitable for environments like smart-home management, body area networks, etc., where the end-points form a closed system and pre-sharing of 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 lightweight yet robust alternative to conventional DTLS with PSK. The present draft explains the generic algorithm and proposes a CoAP specific implementation of the same with the necessary adjustments in the base protocol. The proposed idea could also be leveraged to bring in modifications in DTLS and make DTLS further lightweight yet robust. That work is TBD. 2. The Algorithm The proposed solution is symmetric key based security mechanism where key management is integrated with authentication mechanism. Following the suggested requirements in [I-D.draft-seitz-core-sec- Bhattacharyya, et al. Expires September 3, 2014 [Page 3] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 usecases] the proposed scheme allows mutual authentication between the peers. 2.1. Assumptions A secret is pre-shared between the communicating end-points. This kind of provisioning phase should be common for implementations in applications like smart-home management, body area networks, etc. It is assumed, in agreement with 'the Internet threat model' discussed in section 3 of [I.D.rescorla-sec-cons-05], that the end-devices are tamper-safe so that the security primitives are not compromised. 2.2. Threats considered Broader security threats like disclosure of sensitive information and resource consumption attacks are considered. Thus the proposed scheme considers threats like replay attack, DoS attack, meet-in- the-middle attack, chosen-cipher-text attack. 2.3. Connection initiation and authentication Algorithm-1 below describes the algorithm for mutual authentication and connection initiation. ----------------------------------------------------------------------- Algorithm-1 ----------------------------------------------------------------------- ** Prerequisite: A 128 bit secret Yi is shared between Di (i-th sensor-device) and G (server) offline at provisioning phase. ** Step 1 - Connection initiation: Di sends "HELLO, #Di" to G at the time of session initiation (#Di: unique device ID). ** Step 2 - Server challenge: G responds as AES{Yi, (Yi XOR Ki | nonce1)}, where Ki is the potential session key if the handshake is successful, 'nonce1' is pseudo randomly generated nonce specific to one authentication session. Both Ki and nonce1 is 128 bit each. Total message size is 256 bit. Bhattacharyya, et al. Expires September 3, 2014 [Page 4] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 [Optional: G may perform a table look-up to check if the #Di is valid before challenging client. If #Di is not valid then the handshake does not proceed further.] ** Step 3 - Sensor response and challenge: Di returns AES{Ki, (nonce1 XOR Yi | nonce2)}. Thus if Di is able to decipher the challenge from G then it will have the right nonce1 which is embedded in the response. This completes the client side authentication and key exchange. Also, to check the authenticity of the server, Di challenges G with nonce2, where nonce2 is nonce generated by the client. ** Step 4 - Server response: Server verifies nonce1 and responses to sensor by sending nonce2. ** Result: If nonce2 from G satisfies Di then the mutual authentication is completed and the session key Ki is mutually agreed. ----------------------------------------------------------------------- Figure 1 illustrates the above steps. Bhattacharyya, et al. Expires September 3, 2014 [Page 5] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 Di(Client #i) G(Server) | | | | +--------------------------------->| | Hello, #Di | | | |<---------------------------------| | AES{Yi, (Yi XOR Ki | nonce1)} | | | |--------------------------------->| | AES{Ki, (nonce1 XOR Yi | nonce2)}| | | |<---------------------------------| | AES{Yi, (nonce2 | Ki)} | | | Legends: #Di - ID of device number i, Yi - the pre-shared secret, Ki - the session key, nonce1 - nonce generated by server, nonce2 - nonce generated by client Figure 1: Illustration of steps in Algorithm-1 2.3.1. Nonce generation The 'nonce' is produced by a pseudo random number Ri appended with a timer (counter) Ti. Ri is generated in pseudo-random way, and its inclusion with Ti assures that replay attack is improbable. The non- reproducibility nature of the constructed nonce is governed by Ti and the non-predictable and collision resistance property is governed by Ri. 2.4. CoAP specific implementation This section describes how the proposed scheme can be integrated with CoAP. The inherent reliable delivery 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. Bhattacharyya, et al. Expires September 3, 2014 [Page 6] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 +-----+---+---+---+---+--------------+--------+--------+---------+ | 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 | | | |this. | | | POST |option indicates the type of | | | |authentication request. Value in this | | Auth-Msg-Type| |field determines the response by sever | | | |against POST 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 2 illustrates the handshake. Bhattacharyya, et al. Expires September 3, 2014 [Page 7] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 Client #i Server | | | | +--------------------------------------------->| | POST: CON; MsgID = n; Token = m; | | URI=/.well-known/authorize; | | AUTH = true; | | AUTH-MSG-TYPE = 0; | | Payload= | | | |<---------------------------------------------| | ACK; MsgID = n; Token = m; | | Payload = AES{Yi, (Yi XOR Ki | nonce1)}; | | Response = 2.01 CREATED /session/ | | (if ID not-found then 4.01 UNAUTHORIZED) | | | |--------------------------------------------->| | POST: CON; MsgID = n+1; Token = m; | | AUTH = true; | | AUTH-MSG-TYPE = 1; | | URI= /session/ | | Payload = AES{Ki, (nonce1 XOR Yi | nonce2)}; | | | |<---------------------------------------------| | ACK; MsgID = n+1; Token = m; | | Payload = AES{Yi, (nonce2 | Ki)}; | | Response = 2.04 CHANGED | | (Client authenticated) | | (if received 'nonce1' does not match with | | server copy then 4.01 UNAUTHORIZED) | | | Figure 2. Proposed CoAP specific implementation of Algorithm-1. The 4-way handshake is described below: 1. At initiation, the client sends a POST message in CON mode to a server URI "/.well-known/authorize". The 'Auth' option is set to true. The 'Auth-Msg-Type' set as 'auth_init', and 'device identifier' in the payload. '\authorize' is the resource at the server for initiating authorization activity. 2. The combination of Auth = True and Auth-Msg-Type = 'auth-init' indicates a session initiation to the server. The server derives device identifier from the received payload and determines pre- shared secret associated with that device-identifier. The server Bhattacharyya, et al. Expires September 3, 2014 [Page 8] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 then generates 'nonce1' (server-nonce) and a Key (K). Server forms an encrypted payload comprising nonce1 and K using the shared secret (Y). 3. Server responds back the client with a response code indicating creation of a new resource. The URI in the response indicates a temporary session ID. In case of an invalid device identifier server sends a response code 'Unauthorized'. 4. The client decrypts response received from server and obtains 'nonce1' and 'K'. It generates nonce2 (client-nonce) and then creates encrypted payload using key 'K'. It sends this payload using a POST message with option field 'Auth' and 'Auth-Msg-Type' set to 'response-against-server-challenge'. The same token value as in initiating POST request is kept. 5. Server decrypts payload of the POST message with above mentioned optional values in header using 'K' and checks the received 'nonce1'. Server sends a response with response code 'Changed' to indicate that a change in the resource was authenticated if 'nonce1' is identical with its previous value (generated in step 2), otherwise sends 'Unauthorized'. 3. 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. 4. Integration with DTLS It is envisioned that conventional DTLS can be modified to integrate a scheme like this to develop a robust yet light-weight authentication mechanism within the DTLS framework. Work on this is currently in progress. Details are TBD. 5. Security Considerations The draft itself deals with security. The security considerations are described Section 2 of this document. Bhattacharyya, et al. Expires September 3, 2014 [Page 9] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 6. References 6.1. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013 [I-D.hartke-core-codtls] Hartke, K.,"Datagram Transport Layer Security in Constrained Environments", draft-hartke-core-codtls-02, July 16, 2012 [I-D.draft-seitz-core-sec-usecases] Seitz, L., Gerdes, S. and Selander, G.," Use cases for CoRE security", draft-seitz-core-sec-usecases-00, September 16, 2013 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [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 6.2. Informative References [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 September 3, 2014 [Page 10] Internet-Draft draft-bhattacharyya-core-coap-lite-auth-00 March 2014 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, 2014 [Page 11]