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]