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 draft-jay-tls-psk-identity-extension-02 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 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 routine. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 --------> ServerHello (Certificate) ServerKeyExchange* [with PSK Identity Hint] (CertificateRequest) <-------- ServerHelloDone (Certificate) ClientKeyExchange [with PSK Identity] (CertificateVerify) ChangeCipherSpec Finished --------> ChangeCipherSpec <-------- 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) }ExtensionType; 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 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. 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 messages. The abbreviated handshake is presented below: Client Server ------ ------ ClientHello (with list of PSK Identities in extn) --------> ServerHello with selected PSK Identity in extn) ChangeCipherSpec <-------- Finished ChangeCipherSpec 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 2011. 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, Whitefield, Bengaluru, India EMail: raja.ashok@huawei.com J Kuppannan & R Ashok Expires June 15, 2017 [Page 10]