draft-ietf-tls-ecdhe-psk-aead-01.txt   draft-ietf-tls-ecdhe-psk-aead-02.txt 
Network Working Group J. Mattsson Network Working Group J. Mattsson
Internet-Draft D. Migault Internet-Draft D. Migault
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: May 17, 2017 November 13, 2016 Expires: October 12, 2017 April 10, 2017
ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
for Transport Layer Security (TLS) Security (TLS)
draft-ietf-tls-ecdhe-psk-aead-01 draft-ietf-tls-ecdhe-psk-aead-02
Abstract Abstract
This document defines several new cipher suites for the Transport This document defines several new cipher suites for the Transport
Layer Security (TLS) protocol. The cipher suites are all based on Layer Security (TLS) protocol. The cipher suites are all based on
the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
(ECDHE_PSK) key exchange together with the Authenticated Encryption (ECDHE_PSK) key exchange together with the Authenticated Encryption
with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK
provides light and efficient authentication, ECDHE provides perfect provides light and efficient authentication, ECDHE provides perfect
forward secrecy, and AES-GCM and AES-CCM provides encryption and forward secrecy, and AES-GCM and AES-CCM provides encryption and
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2017. This Internet-Draft will expire on October 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites . . . . . . 3 3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites . . . . . . 3
4. Applicable TLS Versions . . . . . . . . . . . . . . . . . . . 4 4. Applicable TLS Versions . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document defines new cipher suites that provide Pre-Shared Key This document defines new cipher suites that provide Pre-Shared Key
(PSK) authentication, Perfect Forward Secrecy (PFS), and (PSK) authentication, Perfect Forward Secrecy (PFS), and
Authenticated Encryption with Associated Data (AEAD). The cipher Authenticated Encryption with Associated Data (AEAD). The cipher
suites are defined for version 1.2 or later of the Transport Layer suites are defined for version 1.2 of the Transport Layer Security
Security (TLS) [RFC5246] protocol, as well as version 1.2 or later of (TLS) [RFC5246] protocol, version 1.2 of the Datagram Transport Layer
the Datagram Transport Layer Security (DTLS) protocol [RFC6347]. Security (DTLS) protocol [RFC6347], as well as version 1.3 of TLS
[I-D.ietf-tls-tls13].
Pre-Shared Key (PSK) Authentication is widely used in many scenarios. Pre-Shared Key (PSK) Authentication is widely used in many scenarios.
One deployment is 3GPP networks where pre-shared keys are used to One deployment is 3GPP networks where pre-shared keys are used to
authenticate both subscriber and network. Another deployment is authenticate both subscriber and network. Another deployment is
Internet of Things where PSK authentication is often preferred for Internet of Things where PSK authentication is often preferred for
performance and energy efficiency reasons. In both scenarios the performance and energy efficiency reasons. In both scenarios the
endpoints are owned/controlled by a party that provisions the pre- endpoints are owned/controlled by a party that provisions the pre-
shared keys and makes sure that they provide a high level of entropy. shared keys and makes sure that they provide a high level of entropy.
Perfect Forward Secrecy (PFS) is a strongly recommended feature in Perfect Forward Secrecy (PFS) is a strongly recommended feature in
skipping to change at page 3, line 24 skipping to change at page 3, line 26
Elliptic Curve Cryptography for TLS but does not consider PSK Elliptic Curve Cryptography for TLS but does not consider PSK
authentication. [RFC5487] describes the use of AES-GCM in authentication. [RFC5487] describes the use of AES-GCM in
combination with PSK authentication, but does not consider ECDHE. combination with PSK authentication, but does not consider ECDHE.
[RFC5489] describes the use of PSK in combination with ECDHE but does [RFC5489] describes the use of PSK in combination with ECDHE but does
not consider AES-GCM or AES-CCM. not consider AES-GCM or AES-CCM.
3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites 3. ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites
The cipher suites defined in this document are based on the AES-GCM The cipher suites defined in this document are based on the AES-GCM
and AES-CCM Authenticated Encryption with Associated Data (AEAD) and AES-CCM Authenticated Encryption with Associated Data (AEAD)
algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM and AEAD_AES_128_CCM
AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and defined in [RFC5116], and AEAD_AES_128_CCM_8 defined in [RFC6655].
AEAD_AES_256_CCM_8 defined in [RFC6655].
Messages and pre-master secret construction in this document are
based on [RFC4279]. The elliptic curve parameters used in in the
Diffie-Hellman parameters are negotiated using extensions defined in
[I-D.ietf-tls-rfc4492bis].
For TLS1.2, the following cipher suites are defined: For TLS1.2, the following cipher suites are defined:
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD,0xTBD}; TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD,0xTBD};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD,0xTBD}; TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD,0xTBD};
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD,0xTBD}; TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD,0xTBD};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD,0xTBD};
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD,0xTBD}; TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD,0xTBD};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 = {0xTBD,0xTBD};
The assigned code points are only expected to be used for TLS 1.2. The assigned code points can only be used for TLS 1.2.
TLS 1.3 does not follow the same name convention. Instead TLS 1.3
cipher suites are designated according to the AEAD suite as well as
the hash function used. The current combination of AEAD algorithms
and Hash fucntion are already defined in TLS 1.3 so there is no need
to add additional cipher suites for TLS 1.3.
Instead, in order to used the ECDHE_PSK authentication method, TLS
1.3 uses a combination of the "key_share" and
"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
extension sets its mode to psk_dhe_ke. The "key_share" extention
contains a KeyShareEntry structure that carries the ECDHE parameters.
4. Applicable TLS Versions 4. Applicable TLS Versions
The cipher suites defined in this document make use of the The cipher suites defined in this document make use of the
authenticated encryption with additional data (AEAD) defined in TLS authenticated encryption with additional data (AEAD) defined in TLS
1.2 [RFC5246] and DTLS 1.2 [RFC6347]. Earlier versions of TLS do not 1.2 [RFC5246] and DTLS 1.2 [RFC6347]. Earlier versions of TLS do not
have support for AEAD and consequently, these cipher suites MUST NOT have support for AEAD and consequently, these cipher suites MUST NOT
be negotiated in TLS versions prior to 1.2. Clients MUST NOT offer be negotiated in TLS versions prior to 1.2. Clients MUST NOT offer
these cipher suites if they do not offer TLS 1.2 or later. Servers, these cipher suites if they do not offer TLS 1.2 or later. Servers,
which select an earlier version of TLS MUST NOT select one of these which select an earlier version of TLS MUST NOT select one of these
cipher suites. A client MUST treat the selection of these cipher cipher suites. A client MUST treat the selection of these cipher
suites in combination with a version of TLS that does not support suites in combination with a version of TLS that does not support
AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal AEAD (i.e., TLS 1.1 or earlier) as an error and generate a fatal
'illegal_parameter' TLS alert. 'illegal_parameter' TLS alert.
TLS 1.3 and above version, negotiate and support these cipher suites
in a different way.
5. IANA Considerations 5. IANA Considerations
This document defines the following new cipher suites, whose values This document defines the following new cipher suites, whose values
have been assigned in the TLS Cipher Suite Registry defined by have been assigned in the TLS Cipher Suite Registry defined by
[RFC5246]. [RFC5246].
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x01}; TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x01};
TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD; 0xTBD} {0xD0,0x02}; TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 = {0xTBD; 0xTBD} {0xD0,0x02};
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03}; TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x04};
TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x05}; TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 = {0xTBD; 0xTBD} {0xD0,0x05};
TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384 = {0xTBD; 0xTBD} {0xD0,0x06};
The cipher suite numbers listed in the second column are numbers used The cipher suite numbers listed in the second column are numbers used
for cipher suite interoperability testing and it's suggested that for cipher suite interoperability testing and it's suggested that
IANA use these values for assignment. IANA use these values for assignment.
6. Security Considerations 6. Security Considerations
The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347], The security considerations in TLS 1.2 [RFC5246], DTLS 1.2 [RFC6347],
TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM [RFC5288], TLS 1.3 [I-D.ietf-tls-tls13], ECDHE_PSK [RFC5489], AES-GCM [RFC5288],
and AES-CCM [RFC6655] apply to this document as well. and AES-CCM [RFC6655] apply to this document as well.
All the cipher suites defined in this document provide All the cipher suites defined in this document provide
confidentiality, mutual authentication, and perfect forward secrecy. confidentiality, mutual authentication, and perfect forward secrecy.
The AES-128 cipher suites provide 128-bit security and the AES-256 The AES-128 cipher suites provide 128-bit security and the AES-256
cipher suites provide at least 192-bit security. However, cipher suites provide at least 192-bit security. However,
AES_128_CCM_8 only provides 64-bit security against message forgery AES_128_CCM_8 only provides 64-bit security against message forgery.
and AES_256_GCM and AES_256_CCM only provide 128-bit security against
message forgery.
Use of Pre-Shared Keys of limited entropy (for example, a PSK that is Use of Pre-Shared Keys of limited entropy may allow an active
relatively short, or was chosen by a human and thus may contain less attacker attempts to connect to the server and tries different keys.
entropy than its length would imply) may allow an active attacker to For example, limited entropy may be provided by using short PSK in
perform a brute-force attack where the attacker attempts to connect which case an attacker may perform a brute-force attack. Other
to the server and tries different keys. Passive eavesdropping alone example includes the use of a PSK chosen by a human and thus may be
is not sufficient. For these reasons the Pre-Shared Keys used for exposed to dictionary attacks.
authentication MUST have a security level equal or higher than the
cipher suite used, i.e. at least 128-bit for the AES-128 cipher The Pre-Shared Keys used for authentication MUST have a security
suites and at least 192-bit for the AES-256 cipher suites. level equal or higher than the cipher suite used, i.e. at least
128-bit for the AES-128 cipher suites and at least 192-bit for the
AES-256 cipher suites.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Ilari Liusvaara, Eric Rescorla, Dan The authors would like to thank Ilari Liusvaara, Eric Rescorla, Dan
Harkins, Russ Housley, Dan Harkins, Martin Thomson, Nikos Harkins, Russ Housley, Dan Harkins, Martin Thomson, Nikos
Mavrogiannopoulos, Peter Dettman, Xiaoyin Liu and Sean Turner for Mavrogiannopoulos, Peter Dettman, Xiaoyin Liu and Sean Turner for
their valuable comments and feedback. their valuable comments and feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-tls-rfc4492bis]
Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", draft-ietf-tls-
rfc4492bis-16 (work in progress), March 2017.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-18 (work in progress), Version 1.3", draft-ietf-tls-tls13-19 (work in progress),
October 2016. March 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)", Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005, RFC 4279, DOI 10.17487/RFC4279, December 2005,
<http://www.rfc-editor.org/info/rfc4279>. <http://www.rfc-editor.org/info/rfc4279>.
 End of changes. 17 change blocks. 
43 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/