Internet DRAFT - draft-jay-tls-psk-identity-extension
draft-jay-tls-psk-identity-extension
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]
