\
[Search] [txt|xml|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
TLS Working Group                                              T. Putman
Internet-Draft                                          Dyson Technology
Intended status: Informational                          January 31, 2018
Expires: August 4, 2018


  Authenticated Key Agreement using Pre-Shared Asymmetric Keypairs for
   (Datagram) Transport Layer Security ((D)TLS) Protocol version 1.3
                   draft-putman-tls13-preshared-dh-00

Abstract

   This document defines an authenticated key agreement method for the
   Transport Layer Security (TLS) protocol version 1.3.  The
   authentication method requires that the server (and optionally
   client) is pre-provisioned with a unique long-term static asymmetric
   Finite Field Diffie-Hellman (DH) or Elliptic Curve Diffie-Hellman
   (ECDH) keypair; the peer must be able to obtain the public key of the
   endpoint via an out-of-band mechanism (e.g. pre-provisioning).  The
   handshake provides ephemeral (EC)DH keys, and a common key schedule
   is agreed using Double- or Triple-(EC)DH.  Confirmation of knowledge
   of the key schedule provides server (and optionally client)
   authentication.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 4, 2018.

Copyright Notice

   Copyright (c) 2018 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



Putman                   Expires August 4, 2018                 [Page 1]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Rationale for Using Authenticated Key Agreement . . . . .   3
     1.2.  Applicability Statement . . . . . . . . . . . . . . . . .   4
     1.3.  Comparison of 2/3(EC)DH with Other Methods  . . . . . . .   4
     1.4.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  2(EC)DH and 3(EC)DH Key Exchange  . . . . . . . . . . . . . .   5
   3.  Format of 2/3(EC)DH Identity  . . . . . . . . . . . . . . . .   8
   4.  Conformance Requirements  . . . . . . . . . . . . . . . . . .  10
     4.1.  PSK Identity Encoding . . . . . . . . . . . . . . . . . .  10
     4.2.  Requirements for TLS Implementations  . . . . . . . . . .  11
     4.3.  Requirements for Management Interfaces  . . . . . . . . .  11
     4.4.  Precomputation for Constrained Clients  . . . . . . . . .  12
   5.  Cryptographic Operations  . . . . . . . . . . . . . . . . . .  13
     5.1.  Key Schedule  . . . . . . . . . . . . . . . . . . . . . .  13
     5.2.  Client Id Key Calculation . . . . . . . . . . . . . . . .  16
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  17
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     8.1.  Security of 1-RTT Traffic . . . . . . . . . . . . . . . .  17
     8.2.  Security of 0-RTT Traffic . . . . . . . . . . . . . . . .  18
     8.3.  Security of Client Identity . . . . . . . . . . . . . . .  18
     8.4.  Additional Security Observations  . . . . . . . . . . . .  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   Often, constrained devices use pre-shared keys (PSK) for
   authentication and key agreement.  A drawback of this is that if the
   server database of pre-shared keys is compromised, then this means
   that not only can the server be impersonated to the clients, but also
   the symmetric nature of the keys means that the clients can be
   impersonated to the server.

   In consequence, a large-scale database compromise can result in
   large-scale client impersonation.  This is very hard to recover from



Putman                   Expires August 4, 2018                 [Page 2]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   because any remote update to the clients risks providing the updated
   information to an adversary.

   This document describes the use of asymmetric pre-shared keys to
   address this data-loss scenario.  It assumes that an out-of-band
   method of pre-configuring the asymmetric keys into the endpoints
   exists, and this method is outside the scope of this document.  The
   primary intended usage is for constrained devices, but the method may
   be used in other circumstances where the peer's public key may be
   securely obtained out-of-band (e.g. via DNSSEC).

   Another advantage of asymmetric pre-shared keys over symmetric pre-
   shared keys is that it is easier to protect a single server private
   key using hardware-based security than it is to protect a database of
   shared symmetric keys.

1.1.  Rationale for Using Authenticated Key Agreement

   In [I-D.ietf-tls-tls13], all key exchange methods except those based
   on PSK require perfect forward secrecy (PFS), which in turn requires
   (at present) either Diffie-Hellman or Elliptic Curve Diffie-Hellman.
   The number of constrained devices which can be accommodated is
   increased if the key agreement also provides authentication, so that
   no other public key algorithms are required.

   Even if the device contains code for other public key algorithms
   (e.g.  EdDSA for code update signature checking), these may be coded
   to use a slow variant of the algorithm to conserve code and data
   space.  In addition, hardware support for ECDH is likely to be
   introduced in many constrained devices, as it is required for
   wireless communications (e.g.  Bluetooth Mesh), whereas signing
   algorithms are not.

   Double-(EC)DH [Blake-Wilson] could be used for authenticated key
   agreement, but this would not provide PFS.  PFS can be provided by
   using Triple-(EC)DH [Kudla] with no change to the protocol messages;
   it only adds to the cost of computing the keying material by adding
   one additional (EC)DH computation.

   In order to break forward secrecy in Double-(EC)DH, the attacker must
   obtain the static (EC)DH private keys of both client and server.
   This is likely to be a difficult feat, so both Double- and
   Triple-(EC)DH are specified in this document as this increases the
   number of constrained devices which are able to use this method.

   Perfect Forward Secrecy (PFS) is a strongly recommended feature in
   security protocol design and is mandatory to implement in both HTTP/2
   [RFC7540] and (for non-PSK deployments) CoAP [RFC7252].  Therefore,



Putman                   Expires August 4, 2018                 [Page 3]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   Triple-(EC)DH SHOULD be used for those deployments where the client
   devices are able to support the additional computation.

1.2.  Applicability Statement

   The authentication methods defined in this document are primarily
   intended for a narrow set of applications, where there is a well-
   established relationship between clients and servers and where, in
   addition, there are severe constraints on the client capabilities.
   Even in such deployments, other alternatives may be more appropriate.

   If the loss of server data is not of concern, then the use of
   symmetric pre-shared keys may be more appealing.  If, on the other
   hand, the main goal is to avoid Public-Key Infrastructures (PKIs),
   then the use of raw public keys [RFC7250] may be preferrable.

   A secondary use of this authentication method is to support 0-RTT
   traffic in a situation where no (current) session tickets exist.  The
   server in this situation will typically not have knowledge of the
   client, so a method which supports only server authentication is also
   supported.

1.3.  Comparison of 2/3(EC)DH with Other Methods

   The 2/3(EC)DH authenticated key agreement modes offer advantages over
   other schemes, but there are limitations as well.  A summary of
   advantages and disadvantages are given in the following table:
























Putman                   Expires August 4, 2018                 [Page 4]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   +----------------+----------------------------+---------------------+
   | Alternative    | 2/3(EC)DH Advantage        | 2/3(EC)DH           |
   | Authentication |                            | Disadvantage        |
   | Mode           |                            |                     |
   +----------------+----------------------------+---------------------+
   | External PSK   | Server breach does not     | Public-key          |
   |                | permit client              | computations needed |
   |                | impersonation; hardware    |                     |
   |                | protection for server key  |                     |
   |                | possible; client identity  |                     |
   |                | is confidential            |                     |
   |                |                            |                     |
   | Raw Public     | Supports 0-RTT messages;   | Separate server     |
   | Keys           | only one public-key        | keypair needed if   |
   |                | algorithm used; shorter    | it also supports    |
   |                | messages                   | PKI                 |
   |                |                            |                     |
   | Certificate    | Supports 0-RTT messages;   | Out-of-band public  |
   | Authentication | only one public-key        | key distribution    |
   |                | algorithm used; no         | needed (e.g. pre-   |
   |                | certificate parsing; much  | provisioning,       |
   |                | shorter messages           | DNSSEC)             |
   +----------------+----------------------------+---------------------+

1.4.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  2(EC)DH and 3(EC)DH Key Exchange

   This section defines the key exchange mechanisms which are used for
   2(EC)DH and 3(EC)DH.  The message exchange is identical to that used
   for PSK with (EC)DHE key establishment, and is reproduced below in
   Figure 1.  Although the message exchange is identical, the pre-shared
   keys have extra semantics applied and the key schedule is different.












Putman                   Expires August 4, 2018                 [Page 5]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


          Client                                         Server

   Key  ^ ClientHello
   Exch | + key_share
        | + psk_key_exchange_modes
        v + pre_shared_key       -------->
                                                    ServerHello  ^ Key
                                                    + key_share  | Exch
                                               + pre_shared_key  v
                                          {EncryptedExtensions}
                                                     {Finished}  : Auth
                                 <--------  [Application Data*]
   Auth : {Finished}             -------->
          [Application Data]     <------->   [Application Data]

              +  Indicates noteworthy extensions sent in the
                 previously noted message.

              *  Indicates optional or situation-dependent
                 messages/extensions that are not always sent.

              {} Indicates messages protected using keys
                 derived from a [sender]_handshake_traffic_secret.

              [] Indicates messages protected using keys
                 derived from [sender]_application_traffic_secret_N

            Figure 1: Message flow for 2/3(EC)DH TLS Handshake

   Details of the PSK identity format which is used with 2/3{EC}DH is
   given in section Section 3.  To understand the key exchange explained
   here, it only necessary to know that the PSK identity is the
   concatenation of a server PSK identity with an optional encrypted
   client PSK identity.  The server PSK identity is uniquely associated
   with an (EC)DH private/public keypair, and the client PSK identity is
   present if and only if a key share on the named curve corresponding
   to the server PSK identity is present in the ClientHello message.

   The client indicates its willingness to use 2/3(EC)DH authenticated
   key exchange by including at least one compatible identity in its
   "pre_shared_key" extension.  Support for 2(EC)DH versus 3(EC)DH is
   indicated by including the values psk_ke or psk_dhe_ke respectively
   in the "psk_key_exchange_modes" extension; as with other pre-shared
   key methods, psk_ke does not support PFS, whereas psk_dhe_ke does.
   The client MUST NOT include more than one identity which is
   associated with the same server PSK identity: doing so would
   compromise the security of the encrypted client PSK identity.  The
   client MUST also include in the "supported_groups" extension all



Putman                   Expires August 4, 2018                 [Page 6]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   (EC)DH groups which are needed to establish a key exchange for any of
   the provided PSK identities: 2/3(EC)DH key exchange requires that all
   static and ephemeral (EC)DH keys are in the same named group.

   If the TLS server accepts the use of 2(EC)DH or 3(EC)DH, then it
   selects a PSK identity which corresponds to the chosen key exchange
   mode from the list of offered identities in the "pre_shared_key"
   extension of the ClientHello message.  As with other PSK modes, the
   server MUST ensure that the selected PSK and cipher suite are
   compatible, and it may do this by selecting the cipher suite first
   then excluding all incompatible PSKs.

   Prior to accepting PSK key establishment, the server MUST validate
   the corresponding binder value (see Section 4.2.11.2 of
   [I-D.ietf-tls-tls13]).  If this value is not present or does not
   validate, the server MUST abort the handshake.  Servers SHOULD NOT
   attempt to validate multiple binders; rather they SHOULD select a
   single PSK and validate solely the binder that corresponds to that
   PSK.

   The server MUST support 3(EC)DH on each of its server PSK identities,
   and may support 2(EC)DH on any subset of identities (including all or
   none).  The client MAY be willing to establish key exchange either
   with or without PFS, indicated by including both the psk_ke and
   psk_dhe_ke values in the "psk_key_exchange_mode" extension.  If, in
   this situation, the server chooses to use a 2/3(EC)DH identity, then
   it SHALL select the 3(EC)DH key exchange method.  The client MUST
   support this behavior by constructing the corresponding binder using
   the 3(EC)DH binding key; if it does not, then the handshake will
   fail.

   The selected PSK identity identifies a server static (EC)DH private/
   public keypair and implicitly also a named group.  If the ClientHello
   message does not contain a key share for this group, then the server
   SHALL request the key share by sending a HelloRetryRequest which
   indicates the selected PSK identity in the "pre_shared_key"
   extension.  If the ClientHello message does contain a key share for
   this group but the selected identity does not contain an encrypted
   client identity, then the server SHALL abort the handshake with an
   "illegal_parameter" alert.

   A client SHOULD remember which server PSK identity a server preferred
   in previous sessions and SHOULD include the corresponding key share
   in the first ClientHello message when establishing future sessions.
   This will reduce the number of HelloRetryRequest messages from the
   server and will speed up session establishment.





Putman                   Expires August 4, 2018                 [Page 7]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   If the ClientHello is sent in response to a HelloRetryRequest, then
   it MUST only contain the PSK identity selected by the server.  It
   MUST also contain in the "key_share" extension an ephemeral (EC)DH
   key which is on the named curve associated with the server PSK
   identity.  Consequently, the PSK identity will contain both the
   server PSK identity and the encrypted client PSK identity.

   If 2/3(EC)DH PSK key exchange mode is selected, then the server
   decrypts the client identity and, if it is not an anonymous client,
   obtains the corresponding client static public (EC)DH key.  If it
   accepts anonymous clients or if it accepts the identified client,
   then the server responds with a ServerHello message; this message
   MUST include a "pre_shared_key" extension which indicates the
   selected PSK identity and an ephemeral key share in the same named
   group as the selected static (EC)DH key.  It SHALL NOT send
   Certificate or CertificateRequest messages.

   Both peers MUST use the selected ephemeral and static (EC)DH keys to
   derive the key schedule using either 2(EC)DH or 3(EC)DH, depending on
   the selected key exchange mode, as specified in section Section 5.1.

   If the 2/3(EC)DH PSK key exchange mode is selected and the decrypted
   client identity is not recognised, or if it indicates an anonymous
   client and the server is configured to reject anonymous clients, then
   the server SHALL select a valid unused public key to use for the
   purposes of computing the key binding, and only reject the handshake
   when the binding check fails.  This is needed to prevent an oracle
   attack on client identity confidentiality where the attacker replays
   a ClientHello but modifies the encrypted client identity in a
   controlled way.

3.  Format of 2/3(EC)DH Identity

   The format of a PSK identity defined in [I-D.ietf-tls-tls13] is
   opaque<1..2^16-1>, but additional structure is needed to support
   confidentiality of the client PSK identity; this structure remains
   opaque to the protocol, but must be agreed between the end-points
   using an out-of-band mechanism.

   An identity which is associated with 2/3(EC)DH key exchange SHALL be
   the concatenation of a server PSK identity with an optional encrypted
   client PSK identity.

   A server which supports 2(EC)DH and/or 3(EC)DH MUST have one or more
   identities associated with it for the purposes of (EC)DH PSK key
   exchange.  Each identity is associated with a single static (EC)DH
   private/public keypair and Hash algorithm; these identities are




Putman                   Expires August 4, 2018                 [Page 8]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   provided to the clients via an out-of-band mechanism (e.g. pre-
   provisioning) which is outside the scope of this specification.

   To simplify processing, the server PSK identities SHOULD all be the
   same size; if the server has a single PSK identity, then it MAY be
   NULL (zero length), but this is NOT RECOMMENDED as this complicates
   the addition of new identities.  Also, the server SHOULD ensure that
   PSK identities which are established by the session ticket mechanism
   are always distinguishable from 2/3(EC)DH PSK identities; for
   example, if the session ticket is constructed as described in section
   4 of [RFC5077], then the opaque "key_name" should be chosen so that
   it does not collide with any of the server PSK identities.

   The encrypted client PSK identity MUST be present if the
   corresponding key share is present in the "key_share" extension, and
   MUST NOT be present otherwise.  If the server has a NULL identity,
   then the minimum length of the PSK identity requires that the client
   PSK identity must be present; this in turn means that the
   corresponding key share must be present in the "key_share" extension.

   A single server MAY support multiple static (EC)DH keys across one or
   more named curves by having multiple server PSK identities.  This
   allows rotation of static keys on a single curve, or migration from a
   weaker named curve or hash algorithm to a stronger one.  The policies
   required to rotate keys or change curves/hash algorithms are outside
   the scope of this specification, but if such a change is instigated
   then the overlap period during which both keys are supported should
   be sufficiently long to ensure that all clients have been updated.

   As suggested earlier, the server SHOULD ensure that the different PSK
   identities that it is prepared to process are readily
   distinguishable.  If it mis-classes an identity then the binding
   check will fail and the session will not be established.  The
   contents of the server PSK identity field are opaque, so this may be
   done by keeping all PSK identities of this server the same length or
   by preceding the server PSK identity with a length field.  Each
   server PSK identity is associated with a single (EC)DH private/public
   keypair and hash algorithm, so the identity may be formed from a root
   name with the corresponding curve name (and optionally hash
   algorithm) appended.

   When present, the client PSK identity is encrypted.  The encryption
   key is derived as described in section Section 5.1 and depends on the
   client key share (among other things).  For this reason, the client
   PSK identity cannot be present if the corresponding key share is not
   present and this forces the server to send a HelloRetryRequest if
   this server PSK identity is selected.




Putman                   Expires August 4, 2018                 [Page 9]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   Any string of all zero bytes of any length is reserved for an
   anonymous client and MUST NOT be used for an actual client PSK
   identity.  It is RECOMMENDED that all client PSK identities are the
   same length, in which case this length SHOULD be publicised so that
   an anonymous client can use an identity of the same length.
   Alternatively, if different lengths are supported for client PSK
   identities, then the client and server SHOULD support padding of the
   identity with leading zero bytes to prevent client identification by
   correlating the length of the encrypted PSK identity string in
   different handshake sequences.

4.  Conformance Requirements

   It is expected that different types of client and server identities
   are useful for different applications running over TLS.  This
   document does not therefore mandate the use of any particular type of
   identity (such as IPv4 address or Fully Qualified Domain Name
   (FQDN)).

   However, the TLS client and server clearly have to agree on the
   identities and keys to be used.  To improve interoperability, this
   document places requirements on how the identity is encoded in the
   protocol, and what kinds of identities and keys implementations have
   to be supported.

   The requirements for implementations are divided into two categories,
   requirements for TLS implementations and management interfaces.  In
   this context, "TLS implementation" refers to a TLS library or module
   that is intended to be used for several different purposes, while
   "management interface" would typically be implemented by a particular
   application that uses TLS.

   This document does not specify how the server stores the keys and
   identities, or how exactly it finds the key corresponding to the
   identity it receives.  For instance, if the identity is a domain
   name, it might be appropriate to do a case-insensitive lookup.  It is
   RECOMMENDED that before looking up the key, the server processes the
   client PSK identity with a PRECIS framework (see [RFC7564])
   appropriate for the identity in question (such as [RFC5891] for
   components of domain names or [RFC8265] for usernames).

4.1.  PSK Identity Encoding

   The server and client PSK identities MUST be first converted to a
   character string, and then encoded to octets using UTF-8 [RFC3629];
   the server PSK identity MAY be preceded by a single-octet length
   field and the client PSK identity MAY be preceded by a variable
   number of zero octets.  For instance,



Putman                   Expires August 4, 2018                [Page 10]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   o  IPv4 addresses are encoded as dotted-decimal strings (e.g.
      "192.0.2.1"), not as 32-bit integers in network byte order.

   o  Domain names are encoded in their usual text form [RFC1035] (e.g.
      "www.example.com" or "embedded\.dot.example.net"), not in DNS
      protocol format.

   o  X.500 Distinguished Names are encoded in their string
      representation [RFC4514], not as BER-encoded ASN.1.

   This encoding is clearly not optimal for many types of identities.
   It was chosen to avoid identity-type-specific parsing and encoding
   code in implementations where the identity is configured by a person
   using some kind of management interface.  Requiring such identity-
   type-specific code would also increase the chances for
   interoperability problems resulting from different implementations
   supporting different identity types.

4.2.  Requirements for TLS Implementations

   TLS implementations supporting 2/3(EC)DH key agreement MUST support
   arbitrary client PSK Identities up to 128 octets in length, and MUST
   provide a server PSK identity which uses a static ECDH key on the
   named curve P-256.  Supporting longer identities and other ECDH
   curves is RECOMMENDED.

   The server MUST provide information out-of-band regarding what
   format(s) of client PSK identity it supports for each server PSK
   identity, together with the server (EC)DH public key and hash
   function.  This information includes the supported length(s) of the
   client PSK identity, the padding method (if any) and whether it
   accepts anonymous clients or not.

4.3.  Requirements for Management Interfaces

   In the absence of an application profile specification specifying
   otherwise, a management interface for entering the pre-shared
   private/public keys, and/or PSK Identity MUST support the following:

   o  Entering client and server PSK identities consisting of up to 128
      printable Unicode characters.  Supporting as wide a character
      repertoire and as long identities as feasible is RECOMMENDED.

   o  Entering the named curve and hash function which is associated
      with each server PSK identity, or selecting from a pre-set list of
      named curves and hash functions which are supported by the TLS
      implementation.




Putman                   Expires August 4, 2018                [Page 11]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   o  Entering pre-shared private and public keys in the representation
      specified for that named curve in [I-D.ietf-tls-tls13], where each
      value/co-ordinate is in hexadecimal encoding up to the length
      required by the named curve.  Supporting compressed forms and
      longer co-ordinates is RECOMMENDED.  The interface SHOULD validate
      the key which was entered, if possible; that is, check that a
      private key is in the correct range and, for ECDH keys, that a
      public key is a point on the curve in the correct subgroup.

4.4.  Precomputation for Constrained Clients

   A number of computations in this protocol require substantial
   resources from a constrained client.  Some of these may be
   precomputed, which reduces the time taken during the actual session
   establishment, and so may improve the success rate of the handshake.

   If the client only communicates with a small number of servers, then
   the static-static shared secret (C_s/S_s) may be computed once only
   and stored for all future communications, or may be computed offline
   and preprovisioned.  If this is done, then the secret SHOULD be
   protected with the same level of security as is used to protect the
   client private key; exposure of this key would allow the
   impersonation of 0-RTT traffic.  If the client does not store this
   shared secret, then it may compute it before starting the handshake.

   Prior to starting each handshake, the client should accumulate
   sufficient entropy to generate all the session-specific secrets.
   These include the client ephemeral (EC)DH keypair and the
   ClientHello.random value.  Accumulating entropy in a constrained
   device may take a great deal of time; if so, then this should be done
   as a background task.

   Prior to starting each handshake, the client will usually generate
   the ephemeral keypair and use it to compute the ephemeral-static
   (C_e/S_s) shared secret.  These are necessary to encrypt the client
   identity.  If the client has no information about the server's
   preferences, then it may send an initial ClientHello without any key
   share values so that it can learn which curve and server PSK identity
   to use when generating the client ephemeral key.

   If the above precomputations are performed, then during the handshake
   the client only needs to perform one (respectively, two) public key
   operations for 2(EC)DH (respectively, 3(EC)DH) authenticated key
   agreement.  These values are reduced by one for anonymous clients,
   but constrained devices are not expected to use this mode.






Putman                   Expires August 4, 2018                [Page 12]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


5.  Cryptographic Operations

   Some changes are made to the key schedule which is specified in
   section 7.1 of [I-D.ietf-tls-tls13] when computing keys generated
   using the 2/3(EC)DH mode of key exchange.  These changes introduce a
   new derived secret which is used as a basis for encrypting client PSK
   identities as well two new labels which are used for generating
   bindings for the new PSK identities.  Also, the schedule inputs are
   expanded to introduce multiple (EC)DH shared keys, which are the
   basis for this mode's authenticated key agreement.

   In addition, there is a new key calculation which is used to encrypt
   the client PSK identity.

5.1.  Key Schedule

   The key schedule shown below uses the same formatting conventions and
   functions as used in section 7.1 of [I-D.ietf-tls-tls13].  That is,

   o  HKDF-Extract is drawn as taking the Salt argument from the top and
      the IKM argument from the left.

   o  Derive-Secret's Secret argument is indicated by the incoming
      arrow.  For instance, the Early Secret is the Secret for
      generating the client_early_traffic_secret.

   Authenticated key agreement using 2(EC)DH or 3(EC)DH makes use of
   both static and ephemeral (EC)DH keys, and these keys may belong to
   either the client or the server.  This results in four possible ways
   to combine a client key with a server key.  These are shown in the
   key schedule as follows:

   o  C_s/S_s: Shared key generated using the client static (EC)DH key
      and the server static (EC)DH key; this is a block of zeroes if the
      client is anonymous.

   o  C_e/S_s: Shared key generated using the client ephemeral (EC)DH
      key and the server static (EC)DH key.

   o  C_s/S_e: Shared key generated using the client static (EC)DH key
      and the server ephemeral (EC)DH key; this is a block of zeroes if
      the client is anonymous.

   o  C_e/S_e: Shared key generated using the client ephemeral (EC)DH
      key and the server ephemeral (EC)DH key.  This is the same as
      (EC)DHE used by other key agreement modes, but this terminology is
      used here for consistency with the other shared keys.  It is not
      used by 2(EC)DH.



Putman                   Expires August 4, 2018                [Page 13]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   The concatenation of two octet strings is shown using || between the
   strings.

         Server PSK Identity ||
     Server Static (EC)DH Public Key
                    |
                    V
   C_e/S_s -> HKDF-Extract = Client Id Secret
                    |
                    +-----> Derive-Secret(., "client id",
                    |                     Truncate(ClientHello))
                    |              = client_id_secret
                    |
              Derive-Secret(., "derived", "") |         /* 2/3(EC)DH */
                    0                               /* not 2/3(EC)DH */
                    |
                    v
    PSK |  -> HKDF-Extract = Early Secret           /* not 2/3(EC)DH */
   C_s/S_s          |                                   /* 2/3(EC)DH */
                    +-----> Derive-Secret(.,
                    |                     "ext binder" |
                    |                     "res binder" |
                    |                     "2dh binder" |  /* 2(EC)DH */
                    |                     "3dh binder",   /* 3(EC)DH */
                    |                     "")
                    |              = binder_key
                    |
                    +-----> Derive-Secret(., "c e traffic",
                    |                     ClientHello)
                    |              = client_early_traffic_secret
                    |
                    +-----> Derive-Secret(., "e exp master",
                    |                     ClientHello)
                    |              = early_exporter_master_secret
                    v
              Derive-Secret(., "derived", "")
                    |
   (EC)DHE |        v                               /* not 2/3(EC)DH */
   C_s/S_e | --> HKDF-Extract = Handshake Secret          /* 2(EC)DH */
   (C_e/S_e ||      |                                     /* 3(EC)DH */
    C_s/S_e)        +-----> Derive-Secret(., "c hs traffic",
                    |                     ClientHello...ServerHello)
                    |              = client_handshake_traffic_secret
                    |
                    +-----> Derive-Secret(., "s hs traffic",
                    |                     ClientHello...ServerHello)
                    |              = server_handshake_traffic_secret
                    v



Putman                   Expires August 4, 2018                [Page 14]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


              Derive-Secret(., "derived", "")
                    |
                    v
         0 -> HKDF-Extract = Master Secret
                    |
                    +-----> Derive-Secret(., "c ap traffic",
                    |                     ClientHello...server Finished)
                    |              = client_application_traffic_secret_0
                    |
                    +-----> Derive-Secret(., "s ap traffic",
                    |                     ClientHello...server Finished)
                    |              = server_application_traffic_secret_0
                    |
                    +-----> Derive-Secret(., "exp master",
                    |                     ClientHello...server Finished)
                    |              = exporter_master_secret
                    |
                    +-----> Derive-Secret(., "res master",
                                          ClientHello...client Finished)
                                   = resumption_master_secret

   (EC)DH computations can leak information about the private key if the
   peer public key is not valid.  Therefore, all (EC)DH computations in
   the key schedule MUST be preceded by a validity check on the peer
   public key as described in section 4.2.8.1 or section 4.2.8.2 of
   [I-D.ietf-tls-tls13]; additional validity checks may be added as new
   attacks are discovered.  The endpoint MUST terminate the handshake if
   validation fails.  Validation is required even for the static public
   keys, as the security of these keys is likely to be lower than for
   the static private key, and they may be manipulated by an attacker
   even if validation takes place during provisioning.

   The first change to the key schedule defined in [I-D.ietf-tls-tls13]
   introduced to support 2/3(EC)DH is to prepend an HKDF-Extract
   computation to generate the Client Id Secret.  The salt for this
   computation is the concatenation of the server PSK identity with the
   corresponding static public key; the IKM is the secret generated by
   the client ephemeral key and the server static key.  For 2/3(EC)DH
   modes of key agreement, the salt for the next step of the key
   schedule is a secret derived from the Client Id Secret; for other
   modes the salt is a zero block.  This means that this specification
   results in no change to the key schedule for all other modes.

   Next, the IKM for the generation of the Early Secret for 2/3(EC)DH is
   the secret which is generated by the client static key and the server
   static key.  This is a long-term secret which is equivalent to the
   PSK which is the IKM for other PSK modes.  The inclusion of keying
   material based on the client static (EC)DH key provides data origin



Putman                   Expires August 4, 2018                [Page 15]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   authenication for 0-RTT traffic (if present).  For anonymous clients,
   this IKM is a zero block; data origin authentication has no meaning
   in any case for anonymous clients.

   Additional labels are defined for the generation of the binder_key
   which is used to bind the identity and key to the current handshake.
   The label "2dh binder" (respectively "3dh binder") is used if the
   selected mode is 2(EC)DH (respectively 3(EC)DH).

   The last change to the key schedule is to the IKM used to derive the
   Handshake Secret.  As defined in [I-D.ietf-tls-tls13], this is the
   secret generated by the client ephemeral key and the server ephemeral
   key (if available).  For 2(EC)DH, this is the secret generated by the
   client static key and the server ephemeral key.  For 3(EC)DH, this is
   the concatenation of the secrets generated by the client ephemeral
   key and the server ephemeral key, and by the client static key and
   the server ephemeral key in that order.

   All (EC)DH computations are carried out as described in section 7.4
   of [I-D.ietf-tls-tls13].

5.2.  Client Id Key Calculation

   Each offered client PSK identity within a handshake is associated
   with a different server PSK identity, which means that the key
   schedule ensures that a different Client Id Secret is computed for
   each identity.  This means that each derived client_id_secret is
   different within a handshake.

   However, it is possible that a client may re-use an ephemeral key in
   multiple handshakes (though this is bad practice).  If the client
   pads the identity differently or manages multiple identities then
   this will leak identity information.  Therefore, the truncated
   handshake context is included in the computation of the
   client_id_secret to mitigate possible ephemeral key reuse.

   The Truncate() function which is used when computing client_id_secret
   is similar to that used in computing the binding values (see section
   4.2.11.2 of [I-D.ietf-tls-tls13]), except that it excludes the entire
   "pre_shared_key" extension, instead of just removing the binders
   list.  If the ClientHello is sent in response to a HelloRetryRequest
   then the Truncate() function only applies to the second ClientHello;
   the full first ClientHello message is included in the Transcript-Hash
   as defined in section 4.4.1. of [I-D.ietf-tls-tls13].

   The encrypted identity is integrity-protected by the corresponding
   PSK binder, so only encryption is required.  Therefore, the HKDF-
   Expand-Label function is used to generate a keystream of the same



Putman                   Expires August 4, 2018                [Page 16]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   length as the padded client PSK identity and the two are XORed
   together to produce the encrypted identity.  The decryption procedure
   is identical.

   client_id_key = PKDF-Expand-Label(client_id_secret,
                                     "client id",
                                     length(padded client PSK identity))

6.  Acknowledgements

   This document is based on [I-D.putman-tls-preshared-ecdh] and the
   author would like carry over the acknowledgements to this document;
   that is, to thank the authors of [RFC4279], namely Pasi Eronen,
   Hannes Tschofenig, Mohamad Badra, Omar Cherkaoui, Ibrahim Hajjeh and
   Ahmed Serhrouchni; and to thank the author of
   [I-D.harkins-tls-dragonfly], Dan Harkins, for the idea of encrypting
   the client identity.

7.  IANA Considerations

   This document does not define any new IANA considerations.

8.  Security Considerations

   The security considerations in [I-D.ietf-tls-tls13] apply to this
   document as well.

8.1.  Security of 1-RTT Traffic

   The Double- and Triple-Diffie-Hellman authenticated key exchange is
   not particularly new, but it has not seen wide usage.  Triple-ECDH is
   used in the Signal protocol [Marlinspike] and a security proof of
   both, in a modified form of the Bellare-Rogaway model, is provided in
   [Kudla]; this latter paper also proves strong partnering in the
   random oracle model.

   The TLS 1.3 protocol is more complex than the protocol used in the
   above proof, but no additional constraints are made on the components
   of the proof if the client is not anonymous.  All the material which
   is used to compose the key in the proof is also used in constructing
   the Finished messages, with the exception of the pair of static keys:
   instead of including both static keys in the key schedule, the
   derived secret is included; this is equivalent and is done to give
   extra protection against weak ephemeral keys.  The security proof
   therefore also holds for the protocol described in this document if
   the client is not anonymous.





Putman                   Expires August 4, 2018                [Page 17]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   If the client is anonymous, then there is no static client (EC)DH
   keypair.  The security properties of this situation are similar to
   those of DHIES/ECIES [ABR], which also derives a key from a
   combination of an ephemeral and a static (EC)DH key.  The inclusion
   of handshake context in the generation of all session keys protects
   against replay attacks, and the inclusion of the ephemeral-ephemeral
   key in the 3(EC)DH anonymous client situation additionally provides
   PFS in this exchange.  However, none of this is rigorous, and a full
   security analysis of this should be undertaken.

8.2.  Security of 0-RTT Traffic

   The security of the 0-RTT traffic has the same weakened conditions as
   for 0-RTT traffic in other PSK situations, namely that there is no
   PFS and there is no guarantee of traffic uniqueness.

8.3.  Security of Client Identity

   The confidentiality of the client identity in a genuine handshake is
   protected by an ephemeral-static shared secret; this has similar
   properties to DHIES/ECIES [ABR].  The integrity of the key is
   protected by the binder.

   The encrypted client PSK identity does not have any verified client
   information in the keying material.  Therefore an attacker who knows
   the server public key may impersonate a client when sending a client
   key exchange message; this is no different to the other PSK key
   exchange modes and does not affect the security of the completed
   handshake.

   Because a PSK Identity can be forged, the server should ensure that
   there are no PSK Identity retrievals which are more expensive than
   other operations in this protocol; this is to mitigate DoS attacks.
   Additionally, if there are differences in the lookup time of a PSK
   Identity (e.g. if recent lookups are cached), then an attacker may be
   able to obtain information about the PSK Identity of a recent
   handshake from timing attacks.

8.4.  Additional Security Observations

   This key exchange mode allows for the inclusion of 0-RTT traffic from
   a client which has no previous communications with the server, only
   an out-of-band method of obtaining the server PSK information
   (identity, public key, anonymous client support).  This supports
   rapid client authentication at the application level, for example by
   using an authentication token.  However, there is currently no way to
   convey this information to the TLS server, which will continue to
   consider the client to be anonymous.  Further work would be needed



Putman                   Expires August 4, 2018                [Page 18]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   before this use case could be considered to be secure, and it is not
   considered further in this document.

   As with the other PSK key exchange modes, these modes make use of
   hidden information in the construction of the keying material.  This
   means that the cipher suites are quantum-safe in the event that the
   message exchange is stored for later attack, provided that the client
   and/or server static public keys (the pre-provisioned keys) remain
   unknown to the eavesdropper.  In the anonymous client use case, the
   server public keys is likely to be widely known, so this observation
   does not apply.

   The protocol description in this document only refers to finite field
   and elliptic curve Diffie-Hellman keys, but will work for any key
   exchange mechanism which uses public/private keypairs to establish a
   shared secret.  The only change that is needed to support new methods
   (which may include quantum-safe key exchange algorithms) is to
   include their definition in the "key_share" extension.  Any new
   mechanisms which are added to the "key_share" extension MUST include
   a consideration of their effect on this document in their security
   section.

9.  References

9.1.  Normative References

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-23 (work in progress),
              January 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.








Putman                   Expires August 4, 2018                [Page 19]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


9.2.  Informative References

   [ABR]      Abdalla, M., Bellare, M., and P. Rogaway, "DHIES: An
              Encryption Scheme based on the Diffie-Hellman Problem",
              2001,
              <http://web.cs.ucdavis.edu/~rogaway/papers/dhies.pdf>.

   [Blake-Wilson]
              Blake-Wilson, S., Johnson, D., and A. Menezes, "Key
              Agreement Protocols and their Security Analysis",
              Cryptography and Coding volume 1355 of LNCS, 1997.

   [I-D.harkins-tls-dragonfly]
              Harkins, D., "Secure Password Ciphersuites for Transport
              Layer Security (TLS)", draft-harkins-tls-dragonfly-02
              (work in progress), August 2017.

   [I-D.putman-tls-preshared-ecdh]
              Putman, T., "ECDH-based Authentication using Pre-Shared
              Asymmetric Keypairs for (Datagram) Transport Layer
              Security ((D)TLS) Protocol version 1.2", draft-putman-tls-
              preshared-ecdh-00 (work in progress), November 2017.

   [Kudla]    Kudla, C. and K. Paterson, "Modular Security Proofs for
              Key Agreement Protocols", Advances in Cryptology ASIACRYPT
              2005: 11th International Conference on the Theory and
              Application of Cryptology and Information Security, 2005,
              <http://www.isg.rhul.ac.uk/~kp/ModularProofs.pdf>.

   [Marlinspike]
              Marlinspike, M. and T. Perrin, "The X3DH Key Agreement
              Protocol", November 2016,
              <https://www.signal.org/docs/specifications/x3dh/
              x3dh.pdf>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, DOI 10.17487/RFC4279, December 2005,
              <https://www.rfc-editor.org/info/rfc4279>.

   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names",
              RFC 4514, DOI 10.17487/RFC4514, June 2006,
              <https://www.rfc-editor.org/info/rfc4514>.



Putman                   Expires August 4, 2018                [Page 20]


Internet-Draft      Preshared DH Key Auth for TLS 1.3       January 2018


   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <https://www.rfc-editor.org/info/rfc5077>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <https://www.rfc-editor.org/info/rfc7250>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <https://www.rfc-editor.org/info/rfc7540>.

   [RFC7564]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
              Preparation, Enforcement, and Comparison of
              Internationalized Strings in Application Protocols",
              RFC 7564, DOI 10.17487/RFC7564, May 2015,
              <https://www.rfc-editor.org/info/rfc7564>.

   [RFC8265]  Saint-Andre, P. and A. Melnikov, "Preparation,
              Enforcement, and Comparison of Internationalized Strings
              Representing Usernames and Passwords", RFC 8265,
              DOI 10.17487/RFC8265, October 2017,
              <https://www.rfc-editor.org/info/rfc8265>.

Author's Address

   Tony Putman
   Dyson Technology
   Malmesbury  SN16 0RP
   UK

   Email: tony.putman@dyson.com





Putman                   Expires August 4, 2018                [Page 21]