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

Versions: 00 01 02

TLS Working Group                                            J Kuppannan
INTERNET-DRAFT                                                   Juniper
Intended Status: Standard Track                                  R Ashok
Expires: June 15, 2017                                            Huawei
                                                       December 15, 2016

                    TLS/DTLS PSK Identity Extension


   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 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

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

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 1]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

Copyright and License Notice

   Copyright (c) 2016 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  Existing Mechanism of [D]TLS Cipher Negotiation . . . . . . . .  4
   4  Drawbacks in existing PSK handshake . . . . . . . . . . . . . .  5
     4.1  Drawback in existing PSK Cipher Negotiation . . . . . . . .  5
     4.2  Scope of reducing RTT in PSK handshake  . . . . . . . . . .  6
   5 Optimized PSK handshake  . . . . . . . . . . . . . . . . . . . .  6
     5.1 PSKIdentityExtention Type  . . . . . . . . . . . . . . . . .  6
     5.2 PSK Identity Extension Data Specification  . . . . . . . . .  6
     5.3 Abbreviated Handshake  . . . . . . . . . . . . . . . . . . .  8
     5.4 Benefits of Abbreviated Handshake  . . . . . . . . . . . . .  8
   6  Security Considerations . . . . . . . . . . . . . . . . . . . .  9
     6.1 Identity Privacy . . . . . . . . . . . . . . . . . . . . . .  9
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  9
   8  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  9
   9  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     9.2  Informative References  . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 2]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

1  Introduction

   RFC 4279 describes the usage of Pre-Shared Key (PSK) based Cipher
   Suites in TLS. PSK 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.

   Generally both Client and Server may have multiple Pre-Shared Keys
   configured for communicating with different parties. As part of PSK
   handshake, PSK ID send in client key exchange helps both the entity
   to negotiate the Pre-Share Key which needs to be used. This document
   defines a new Hello message extension for proposing and finalizing
   the Pre-Shared key to be used between Client and Server. This new
   extension helps in reducing the number of independent messages
   exchanged and also in reducing the RTT for the entire handshake

   This document currently focuses only on [D]TLS 1.2 and prior protocol
   versions(TLS 1.1, TLS 1.0 and DTLS 1.0). TLS 1.3 (work in-progress)
   also considers including a similar extension as the one proposed
   here. But that TLS 1.3 extension cannot be used in lower version. So
   a similar extension is proposed in this document, which is totally a
   new and different extension compared to the PreSharedKey extension in
   TLS 1.3. In future also not all system in world will be running
   [D]TLS 1.3. So proposing this new extension in older version of
   [D]TLS is beneficial.

   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 for all types of PSK
   cipher suites (PSK, DHE_PSK, RSA_PSK and ECDHE_PSK) defined in RFC
   4279, RFC 4785 and RFC 5489.

1.2  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [KEYWORDS].

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 3]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

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 indicate its 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 and
   places the selected cipher suite in the Server Hello Message.

   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             -------->

                                              [with PSK Identity Hint]
                              <--------       ServerHelloDone

      [with PSK Identity]
      Finished                -------->

                              <--------       Finished

3  Existing Mechanism of [D]TLS Cipher Negotiation

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 4]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

   In [D]TLS a cipher suite represents authentication algorithm, key
   exchange algorithm and data protection algorithm (Encryption and
   MAC). Client Hello and Server Hello message of TLS handshake
   negotiates the cipher suite for a connection. At first client sends
   the list of supported ciphers in its "Client Hello" message. On
   receiving this message, server selects one among them and sends back
   in its "Server Hello" message. At this stage, server selects cipher
   based on its priority and its supportability. Here server checks the
   supportability of a cipher, based on the availability of that
   algorithm and the credential required for that algorithm.

   Server does the below task to find out the supportability of a cipher
   before selecting it.
      a) Authentication algorithm : If it is certificate (RSA, DSA,
      ECDSA) based authentication, it checks whether it can support that
      crypto algorithm and it has a X509 certificate and private key. If
      it is PSK based authentication, it checks whether it supports PSK
      based authentication for its client.
      b) Key exchange algorithm : If it is a Diffie-Hellman (DHE, ECHDE)
      based key exchange, it checks whether it can support that crypto
      algorithm. If it is RSA certificate based key exchange, it checks
      whether it supports RSA data encryption and decryption.
      c) Data protection algorithm : It checks whether it can support
      that crypto algorithm (Encryption with MAC or AEAD).

4  Drawbacks in existing PSK handshake

4.1  Drawback in existing PSK Cipher Negotiation

   Consider a client and a server can support both PSK based cipher and
   Certificate based cipher. In this case client sends PSK based and
   Certificate based cipher in its client hello message. If a server
   selects PSK cipher then during 2nd RTT client reveals its PSK
   Identity in Client Key exchange message. At this time if that PSK ID
   is not known to server, then it fails. So selecting PSK cipher
   without knowing Client's PSK Identity is not beneficial if both
   entity can support other types of cipher.

   Similar problem is there in certificate based cipher, which has been
   solved by "trusted_ca_keys" extension. Server might be holding
   multiple certificates issued by different CA. Server can choose any
   one of them and send it to client. But if client is not having that
   corresponding CA certificate, then handshake fails. For preventing
   this late failure, there is a "trusted_ca_keys" extension specified
   in RFC6066. In this extension, client can send the details about all
   the CA certificate which it possess. Based on that server selects

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 5]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

   certificate based cipher only if it holds any end entity certificate
   issued by any one of the CA known to client. So basically this
   "trusted_ca_keys" extension provides additional information about the
   client's capability, this helps server to take right decision  in
   cipher selection.

   Similar feasibility is not there for PSK cipher, because of this we
   are not able to prevent the late handshake failure. So if a client
   can sends its PSK ID in a new extension in its client hello message,
   then it would be more helpful for cipher selection in server.

4.2  Scope of reducing RTT in PSK handshake

   If a client can send its PSK ID (or list of PSK ID) in its client
   hello, then server can respond back the selected PSK ID in its server
   hello. So no need of sending client key exchange message. This can
   make the [D]TLS handshake as 1 RTT. This is applicable only for the
   PSK cipher which performs both authentication and key exchange using
   PSK (not for DHE_PSK, RSA_PSK and ECDHE_PSK).

5 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 in the hello message, about 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.

5.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)

   This psk_identity extension is similar to the PreSharedKeyExtension
   proposed in TLS 1.3, but not same.

5.2 PSK Identity Extension Data Specification

   PSK Identity extension allows the client and server to negotiate the

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 6]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

   PSK Identity which needs 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 MUST include this extension only if
   the received Client Hello had this extension, else the same MUST not
   be included. And server MUST include this extension only if it
   selects any PSK cipher. 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, then it MUST include only one psk_identity in
   the extension data.

   The extension data field for this extension SHALL contain the

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

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

   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.

   The PSK identity send in identity_list MUST be UTF-8 [UTF8] format,
   as specified in Section 5.1 of RFC 4279.

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 7]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

5.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 its own change cipher spec and finished

   The abbreviated handshake is presented below:

      Client                                  Server
      ------                                  ------
      (with list of PSK
      Identities in extn)     -------->

                                              with selected PSK
                                              Identity in extn)
                              <--------       Finished

      Finished                -------->

   This abbreviated  handshake is not applicable for cipher which uses
   PSK only for authentication (DHE_PSK, RSA_PSK, ECDHE_PSK). Because
   here server key exchange and client key exchange messages are
   required to exchange the parameters of DHE, RSA or ECDHE.

5.4 Benefits of Abbreviated Handshake

   The above flow effectively reduces the round trip time for PSK Cipher
   handshake from 2 to 1. The number of messages exchanged is also
   reduced from 9 to 6. For DHE_PSK, RSA_PSK and ECDHE_PSK cipher this
   extension gives more information about the PSK key it possess during
   cipher selection.

   Incase of unmatched pre-shared key scenario, earlier the error gets

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 8]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

   discovered by server only after receiving the Client Key Exchange
   message. This procedure helps in early detection of pre-shared key
   mismatch and helps the server in making an informed decision about
   cipher selection.

6  Security Considerations

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

6.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.

7  IANA Considerations

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

   we recommend to IANA to consider the value of 10015 for the
   psk_identity extension.

8  Acknowledgements

   We would like to thank Nikos Mavrogiannopoulos and David Woodhouse
   for their inputs towards this document.

9  References

9.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.

   [RFC4785]  Blumenthal, U. and P. Goel, "Pre-Shared Key (PSK)
              Ciphersuites with NULL Encryption for Transport Layer
              Security (TLS)", RFC 4785, January 2007.

J Kuppannan & R Ashok    Expires June 15, 2017                  [Page 9]

INTERNET DRAFT      TLS/DTLS PSK Identity Extension    December 15, 2016

   [RFC5485]  Housley, R., "Digital Signatures on Internet-Draft
              Documents", RFC 5485, March 2009.

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

9.2  Informative References

   [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.

Authors' Addresses

   Jayaraghavendran Kuppannan
   Juniper Networks
   Elnath-Exora Business Park,
   Prestige Tech Park, Marathalli,
   Bengaluru, India

   EMail: jayaraghavendran.ietf@gmail.com

   Raja Ashok V K
   Huawei Technologies
   Divyasree Tech Park,
   Bengaluru, India

   EMail: raja.ashok@huawei.com

J Kuppannan & R Ashok    Expires June 15, 2017                 [Page 10]

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