TLS/DTLS PSK Identity Extension
draft-jay-tls-psk-identity-extension-00

TLS Working Group                                     Jayaraghavendran K
Internet-Draft                                       Huawei Technologies
Intended Status: Standards Track                          Raja Ashok V K
Expires: March 31, 2016                              Huawei Technologies
                                                      September 28, 2015

                    TLS/DTLS PSK Identity Extension
                draft-jay-tls-psk-identity-extension-00

Abstract

   Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
   in constrained environments where resource intensive Asymmetric
   Cryptography cannot be used. In the Internet of Things (IoT)
   deployments, constrained devices are commonly used for collecting
   data via sensors for use in home automation, smart energy etc. In
   this context, DTLS is being considered as the primary protocol for
   communication security at the application layer and in some cases, it
   is also being considered for network access authentication.

   This document provides a specification for a new extension for
   Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
   Key Exchange is used. This extension is aimed at reducing the number
   of messages exchanged and the RTT of the TLS & DTLS Handshakes. 

Status of this Memo

   This Internet-Draft is submitted to IETF 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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html
 

Jay & Ashok              Expires March 28, 2016                 [Page 1]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

   This Internet-Draft will expire on March 28, 2016.

Copyright and License Notice

   Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1 Applicability Statement  . . . . . . . . . . . . . . . . . .  3
     1.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2 PSK based (D)TLS Handshake . . . . . . . . . . . . . . . . . . .  4
   3 Drawback of Existing PSK handshake . . . . . . . . . . . . . . .  4
     3.1 Existing Mechanism of Cipher Negotiation . . . . . . . . . .  5
     3.2 Drawbacks for PSK based on existing mechanism  . . . . . . .  5
   4 Optimized PSK handshake  . . . . . . . . . . . . . . . . . . . .  6
     4.1 PSKIdentityExtention Type  . . . . . . . . . . . . . . . . .  6
     4.2 PSK Identity Extension Data Specification  . . . . . . . . .  6
     4.3 Abbreviated Handshake  . . . . . . . . . . . . . . . . . . .  7
     4.4 Benefits of Abbreviated Handshake  . . . . . . . . . . . . .  8
   5 Security Considerations  . . . . . . . . . . . . . . . . . . . .  8
     5.1 Identity Privacy . . . . . . . . . . . . . . . . . . . . . .  8
   6 IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  9
   7 References . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1 Normative References . . . . . . . . . . . . . . . . . . . .  9
     7.2 Informative References . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9

 

Jay & Ashok              Expires March 28, 2016                 [Page 2]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

1 Introduction

   RFC 4279 describes the usage of Pre-Shared Key (PSK) based Cipher
   Suites in TLS. Pre-Shared Keys depending on the cipher suite can
   avoid the need for public key operations. This is useful for all
   those cases where TLS or DTLS are used in resource constrained
   environments with limited CPU power and memory. The advancements in
   Internet of Things (IoT) domain where many constrained devices are
   involved has brought more limelight on DTLS and particularly on the
   usage of PSK based cipher suites in DTLS. CoAP (RFC 7252), which is
   one among the preferred application layer protocols for IoT, mandates
   the use of DTLS for communication security and specifies Pre-Shared
   Key among others as the preferred key exchange mechanism.

   Both Client and Server may have multiple Pre-Shared Keys configured
   for communicating with different parties. This document defines a
   mechanism for proposing and finalizing the Pre-Shared key to be used
   between Client and Server from the set of keys available between them
   using the Client Hello and Server Hello messages itself. This new
   extension helps in reducing the number of independent messages
   exchanged and also in reducing the RTT for the entire handshake
   routine.

   This document currently focuses only on TLS 1.2 / DTLS 1.2 and prior
   protocol versions. TLS 1.3 (work in-progress) also considers
   including a similar extension as the one proposed here for reducing
   RTT. But, since TLS 1.3 will take more time to complete and come into
   use, the pre-shared key extension is being proposed here for TLS /
   DTLS prior versions. This is important considering the emergence of
   IoT, where many devices will be using DTLS 1.2 based on
   recommendation in the CoAP RFC (RFC 7252).

   The reader is expected to be familiar with TLS PSK based Handshake
   though an overview is given in the below sections.

1.1 Applicability Statement

   The idea proposed in this document is applicable only for the cipher
   suites which use the plain Pre-Shared Key Exchange Mechanism. It is
   not applicable for cipher suites which use the DHE_PSK or RSA_PSK Key
   Exchange Mechanisms.

1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

 

Jay & Ashok              Expires March 28, 2016                 [Page 3]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

2 PSK based (D)TLS Handshake

   PSK Key Exchange Algorithm and handshake sequence is listed in
   section 2 of RFC "Pre-Shared Key Cipher suites for Transport Layer
   Security" [RFC4279]. A basic overview is listed below for reference.

   Incase of a PSK based handshake, the client indicates it's
   willingness to use pre-shared Key authentication by including one or
   more PSK cipher suites in the Client Hello message. If the Server
   also wants to use pre-shared keys, it selects one of the PSK cipher
   suites, places the selected cipher suite in the Server Hello Message,
   and includes an appropriate ServerKeyExchange message.
   ServerKeyExchange message is optional though. The certificate and
   certificate request payloads are omitted from the response.

   Both Client and Server may have pre-shared keys with several
   different parties. The client indicates which key to use by including
   a "PSK Identity" in the ClientKeyExchange message. To help the client
   in selecting which key to use, server can provide a "PSK Identity
   Hint" in the ServerKeyExchange message. If no hint is provided, the
   ServerKeyExchange message can be omitted.

   The (D)TLS PSK Handshake is shown below. "*" indicates situation
   dependent messages.

      Client                                          Server
      ------                                          ------

      ClientHello             -------->                     

                                             ServerHello
                                             ServerKeyExchange*
                                             (with PSK Identity Hint)
                              <--------      ServerHelloDone

      ClientKeyExchange                                     
      (with PSK Identity)
      ChangeCipherSpec                                    
      Finished                -------->                     

                                            ChangeCipherSpec
                              <--------             Finished

3 Drawback of Existing PSK handshake

 

Jay & Ashok              Expires March 28, 2016                 [Page 4]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

3.1 Existing Mechanism of Cipher Negotiation

   The drawback in the existing PSK Handshake primarily stems from the
   existing mechanism of cipher negotiation in TLS/DTLS Handshakes. In
   the existing mechanism, the client will first send the list of cipher
   suites in it's Client Hello message which is a combination of Key
   Exchange, Symmetric and MAC Algorithms. Server then selects one among
   the ciphers proposed in the Client Hello and replies with a Server
   Hello message indicating the chosen cipher. The trouble lies on the
   cipher selection mechanism of server. For Symmetric and MAC
   Algorithms, there is no confusion, as the Client and Server only need
   to check if they support the Algorithm, as the credentials (Keys)
   needed for these algorithms will be generated as a part of the
   TLS/DTLS Handshake. 

   For Key Exchange Algorithm, in addition to checking for algorithm
   support, Server should also check if it has the corresponding
   credentials. This especially holds good for certain cases like the
   certificate based Key Exchanges where the Server needs to share it's
   certificate with the Client. But, server still lacks the information
   related to CA root keys available with the client. This especially is
   necessary for scenarios where a constrained client is involved which
   may possess only a small number of CA root keys.

   To solve this problem, "trusted_CA_Keys" extension was introduced in
   which the client will share the information about the CA root keys
   they possess in the Client Hello message. This will in turn help the
   server to check if the certificate which it has, will be acceptable
   to the client and thus help the server in making an informed decision
   in the selection of ciphers.

3.2 Drawbacks for PSK based on existing mechanism

   Incase of PSK, client proposes a PSK based cipher only when it has
   one or more pre-shared keys with itself. Similarly server selects a
   PSK based cipher, when it also has one or more pre-shared keys. But,
   during this cipher negotiation through hello messages, neither party
   has the knowledge about the exact set of pre-shared keys possessed by
   the other. The pre-shared key intended to be used for this session is
   informed later by the client in the ClientKeyExchange message. If the
   server finds that, there is no key corresponding to the identity sent
   by client in the ClientKeyExchange Message, it may terminate the
   connection with an immediate alert or may continue with the handshake
   and fail in the later messages. The disadvantage with this approach
   is that, the mismatch is detected much later in the handshake. In
   case of such a handshake failure, the only option available with
   client is to try the handshake again with a different PSK identity,
   till it exhausts all possible options it has for this server.
 

Jay & Ashok              Expires March 28, 2016                 [Page 5]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

   Also, the existing PSK based Handshake consumes 2 round trip times
   for completing the handshake. The mechanism proposed in this document
   reduces the handshake time to 1 round trip time while also avoiding
   the above mentioned drawback.

4 Optimized PSK handshake

   To avoid the drawbacks mentioned in the above section and also to
   reduce the number of messages exchanged and the round trip time for
   the handshake, it will be better if both the Client and Server have
   the ability to negotiate which pre-shared Key to use among the set of
   pre-shared keys available with them. This document proposes a new
   extension for providing this ability to clients and servers. 

4.1 PSKIdentityExtention Type

   This document defines a new extension type (psk_identity(TBD)), which
   is used in the ClientHello and ServerHello messages. The extension
   type is specified as follows:

            enum {
               psk_identity(TBD), (65535)
            }ExtensionType;

4.2 PSK Identity Extension Data Specification

   PSK Identity extension allows the client and server to negotiate PSK
   Identity to be used for the current session. Clients supporting this
   extension should include it in their client hello message and list
   all the PSK Identities they possess as a part of this extension.
   Clients MAY alternately list only a subset of identities they
   possess.

   Server on receiving this extension should parse through the
   identities in the list, select one among them depending upon it's own
   list of identities and include it as a part of PSK Identity extension
   in the Server Hello. If none of identities sent by client match with
   the list available at the server, it SHOULD choose a Non-PSK cipher
   or abort the connection with "No Shared Ciphers" alert. 

   Clients and Servers wishing to use this extension should include an
   extension of type "psk_identity" in their extended Client and Server
   Hellos. Please note that, Server SHOULD include this extension only
   if the received Client Hello had this extension, else the same should
 

Jay & Ashok              Expires March 28, 2016                 [Page 6]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

   not be included. Similarly, a Server not wishing to negotiate the PSK
   Identity as a part of Hello Messages can ignore this extension. If
   server wishes to include this extension as a part of server hello
   message, it MUST include only one psk_identity in the extension data.

   The extension data field for this extension SHALL contain the
   following:

            opaque psk_identity<1..2^16-1>;

            struct{
               select (Role){
                  case client:
                     psk_identity identity_list<1..2^16-1>;

                  case server:
                     psk_identity identity;
               }
            }PSKIdentityExtension;

   If client receives a server hello with PSK cipher and without PSK ID
   extension, then it MUST perform the legacy PSK handshake as specified
   in RFC 4279. If client receives a server hello message with Non-PSK
   cipher but, with PSKIdentity Extension or if the server hello
   contains a psk identity not from the list sent by client, then it
   MUST fail the handshake with illegal parameter alert.

4.3 Abbreviated Handshake

   Once, the client and server have negotiated the Pre-Shared Key Cipher
   and Identity to be used through the Client Hello and Server Hello
   message extensions as discussed in the previous section, server can
   directly send the Change Cipher Spec and Finished Messages.
   ServerKeyExchange and ClientKeyExchange messages can be avoided
   completely as the information exchanged in those messages are now
   already exchanged using hello extensions. 

   The handshake flow, similar to that of session resumption can be used
   here. On receiving the client hello, the server responds with a
   server hello, followed by change cipher spec and finished message.
   Client on receiving server hello, change cipher spec and finished
   message, responds with it's own change cipher spec and finished
   messages.

   The abbreviated handshake is presented below:

 

Jay & Ashok              Expires March 28, 2016                 [Page 7]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

      Client                               Server
      ------                               ------

      ClientHello                         
      (with list of PSK
      Identities in extension) --------> 

                                          ServerHello
                                          (with selected PSK
                                          Identity in extension) 
                                          ChangeCipherSpec
                              <--------   Finished

      ChangeCipherSpec                                    
      Finished                -------->                     

4.4 Benefits of Abbreviated Handshake

   The above flow effectively reduces the round trip time for Pre-Shared
   Key Cipher based handshake from 2 to 1. The number of messages
   exchanged is also reduced from 9 to 6.

   Incase of unmatched pre-shared key scenario, previously, the error
   will be discovered only after the Client Key Exchange message is
   received from the client which is quite late into the handshake. This
   procedure helps in early detection of pre-shared key mismatch and
   helps the server in making an informed decision about cipher
   selection.

5 Security Considerations

   General security considerations for DTLS and TLS are covered in
   [RFC5246] and [RFC6347].

5.1 Identity Privacy

   All (or subset of) the PSK Identities held by the client are sent in
   the clear text. It should be noted that this doesn't introduce any
   new security concern as an attacker who has the capacity to sniff the
   traffic sent by client can get the list of all identities possessed
   by it by capturing and analyzing the traffic flowing from client to
   various servers.

 

Jay & Ashok              Expires March 28, 2016                 [Page 8]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

6 IANA Considerations

   IANA is requested to add an entry to the existing TLS ExtensionType
   registry, defined in TLS [RFC5246], for psk_identity(TBD) defined in
   this document.

7 References

7.1 Normative References

   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4279]  Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, December 2005.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

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

7.2 Informative References

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066, January
              2011.

Authors' Addresses

   Jayaraghavendran K
   Huawei Technologies,
   Near EPIP Industrial Area,  
   Kundalahalli Village,
   Bangalore, India

   EMail: jayaraghavendran.k@huawei.com

   Raja Ashok V K
   Huawei Technologies,
   Near EPIP Industrial Area,  
 

Jay & Ashok              Expires March 28, 2016                 [Page 9]
Internet-Draft      TLS/DTLS PSK Identity Extension       September 2015

   Kundalahalli Village,
   Bangalore, India

   EMail: raja.ashok@huawei.com

Jay & Ashok              Expires March 28, 2016                [Page 10]