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

Versions: 00

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)


   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-

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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

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.

   ** 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= <Device ID>                   |
   |                                              |
   | ACK; MsgID = n; Token = m;                   |
   | Payload = AES{Yi, (Yi XOR Ki | nonce1)};     |
   | 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{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

   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


   Shelby, Z., Hartke, K. and Bormann, C.,"Constrained Application
   Protocol (CoAP)", draft-ietf-core-coap-18, June 28, 2013


   Hartke, K.,"Datagram Transport Layer Security in Constrained
   Environments", draft-hartke-core-codtls-02, July 16, 2012


   Seitz, L., Gerdes, S. and Selander, G.," Use cases for CoRE
   security", draft-seitz-core-sec-usecases-00, September 16, 2013


   Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security
   Version 1.2", RFC 6347, January 2012.


   Rescorla, E. and Korver, B., "Guidelines for Writing RFC Text on
   Security Considerations", draft-rescorla-sec-cons-05, April 2002

6.2. Informative References


   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]

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