Internet DRAFT - draft-bhattacharyya-core-coap-lite-auth
draft-bhattacharyya-core-coap-lite-auth
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= <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
(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]
