[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
Network Working Group                                        R. Van Rein
Internet-Draft                                               T. Vrancken
Intended status: Informational                          InternetWide.org
Expires: July 25, 2020                                  January 22, 2020

                  Quantum Relief with TLS and Kerberos


   This specification describes a mechanism to use Kerberos
   authentication within the TLS protocol.  This gives users of TLS a
   strong alternative to classic PKI-based authentication, and at the
   same introduces a way to insert entropy into TLS' key schedule such
   that the resulting protocol becomes resistant against attacks from
   quantum computers.  We call this Quantum Relief, and specify it as
   part of a more general framework to make it easier for other
   technologies to achieve similar benefits.

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 July 25, 2020.

Copyright Notice

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

Van Rein & Vrancken       Expires July 25, 2020                 [Page 1]

Internet-Draft                   TLS-KDH                    January 2020

   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
   2.  Quantum Relief as a General Mechanism . . . . . . . . . . . .   3
     2.1.  Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . .   4
   3.  TLS-KDH for Quantum Relief through Kerberos . . . . . . . . .   4
     3.1.  Injecting Kerberos-derived Entropy  . . . . . . . . . . .   5
     3.2.  Client-to-Server Flow . . . . . . . . . . . . . . . . . .   5
     3.3.  Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . .   6
   4.  New Data Types and Procedures . . . . . . . . . . . . . . . .   6
     4.1.  Quantum Relief Extension  . . . . . . . . . . . . . . . .   6
     4.2.  Ticket-based Encryption Procedure . . . . . . . . . . . .   8
     4.3.  Kerberos Ticket and TGT . . . . . . . . . . . . . . . . .   9
     4.4.  Certificate Types . . . . . . . . . . . . . . . . . . . .   9
   5.  Changes to TLS Messages and Behaviour . . . . . . . . . . . .   9
     5.1.  ClientHello . . . . . . . . . . . . . . . . . . . . . . .   9
     5.2.  ServerHello . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Server-sent CertificateRequest  . . . . . . . . . . . . .  11
     5.4.  Server-sent Certificate and CertificateVerify . . . . . .  11
     5.5.  Client-sent Certificate and CertificateVerify . . . . . .  12
     5.6.  Length of Finished  . . . . . . . . . . . . . . . . . . .  12
     5.7.  Selection of Cipher Suites  . . . . . . . . . . . . . . .  12
     5.8.  Tickets and Connection Expiration . . . . . . . . . . . .  12
   6.  Cryptographic Modes . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Quantum Relief for Encryption in TLS 1.3  . . . . . . . .  13
     6.2.  Quantum Relief for Encryption in TLS 1.2  . . . . . . . .  14
     6.3.  Kerberos Ticket as Certificate and CertificateVerify  . .  14
   7.  KDH-Only Application Profile  . . . . . . . . . . . . . . . .  15
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
     8.1.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .  16
     8.2.  Server Authentication . . . . . . . . . . . . . . . . . .  16
     8.3.  Client Authentication . . . . . . . . . . . . . . . . . .  16
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  18
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   TLS protects many application protocols from many security problems.
   To enable this, it habitually relies on public-key cryptography.  But
   in the foreseeable future, quantum computers are expected to destroy
   these public-key underpinnings.  This endangers TLS, because

Van Rein & Vrancken       Expires July 25, 2020                 [Page 2]

Internet-Draft                   TLS-KDH                    January 2020

   encrypted data may be captured and stored, ready for decryption as
   soon as quantum computers hit the playing field.

   With present-day applications of TLS threatened by quantum computers,
   some may not be able to live up to user's legal requirements for
   long-term encryption.  There even is a risk of future power
   imbalances between those who have a quantum computer and those who
   have not.

   One solution is to not rely solely on public-key cryptography, but
   instead mix in secret entropy that a future quantum computing entity
   cannot decipher.  In this light, Kerberos offers an interesting
   perspective, as it builds a symmetric-key infrastructure including
   cross-realm connectivity options.  Kerberos is considered safe from
   quantum computers, as long as its public-key extensions are avoided.

   Herein, we specify a quantum_relief extension that mixes secret
   entropy from another source into the TLS key computations.  This
   concrete mechanism, which relies on Kerberos for relief against
   quantum computing and on (Elliptic-Curve) Diffie-Hellman for Perfect
   Forward Secrecy (and to stop the sphere of influence of the KDC
   administrator), shall be referred to as Kerberised Diffie-Hellman or
   KDH.  A definition is included for a KDH-Only Application Profile, to
   facilitate small and simple implementations.

2.  Quantum Relief as a General Mechanism

   The PSK mechanism in TLS 1.3 and 1.2 allows insertion of key material
   which is referenced by name alone.  A naming system is defined, but
   its interpretation resides under local policy, which is enough for
   internal use cases, but it is insufficient for general use between
   any two parties.

   Cryptographically however, the entropy from the PSK mechanism in TLS
   1.3 is secret to external observers, and mixed with the DHE material
   using a series of HKDF-Extract and -Expand operations [[RFC5869]].
   When used on their own, the DHE material can be reversed by quantum
   computers and any subsequent HKDF computations redone, uncovering the
   complete key schedule of TLS.  The extra source of entropy inserted
   for a PSK however, will have to be uncovered separately, and this
   will not be possible in the general case.

   This specification therefore defines a quantum_relief extension that
   replaces the locally useful PSK scheme with a generally usable
   mechanism for the insertion of secret entropy into the TLS 1.3 key
   schedule at the position otherwise used by the PSK; this sacrifices
   support for 0-RTT data in TLS 1.3.  In TLS 1.2, an extension to the
   computation of the master secret inserts the extra entropy.

Van Rein & Vrancken       Expires July 25, 2020                 [Page 3]

Internet-Draft                   TLS-KDH                    January 2020

   In order to provide sufficient Quantum Relief the added entropy must
   meet the following conditions:

   o  The amount of entropy must on its own suffice for the security
      level of the TLS connection.

   o  The entropy should only be known to parties that are not expected
      to operate a quantum computer (for example because they are
      nearby, contractually bound or otherwise within batting range).

   o  Only quantum-proof mechanisms should be used for the generation of
      the entropy.

   In terms of algorithms that are commonplace today, the third
   requirement is generally believed to be met by secure hashes and
   symmetric encryption.  The problem with these is sharing random
   information secretely and at the same time controlling who has access
   to these secrets.

2.1.  Peer-to-Peer Flow

   Besides the customary client-to-server flow there is also support for
   a peer-to-peer flow under Quantum Relief.  When this is used, the
   ClientHello sent to a TLS server by an initiating peer holds a
   peernametype other than "none" followed by a corresponding name for
   the responding peer.

   Without documenting it here, the TLS server is assumed to have some
   method of locating a responding peer with this information, and
   proxying the entire TLS connection to its endpoint.  The only service
   performed by the TLS server is relaying the literal TLS connection
   between the initiating client/peer and this responding peer.  The TLS
   server is not involved in cryptographic computations for the TLS

3.  TLS-KDH for Quantum Relief through Kerberos

   TLS-KDH is a mode of using TLS that was designed to provide two
   things, (1) an alternative to PKIX credentials in TLS [RFC5280] and
   (2) Quantum Relief for TLS connections.

   The infrastructure of Kerberos provides a good balance between the
   requirements for a Quantum Relief mechanism, as a result of key
   derivation to hierarchical expansion of locally controlled secrets.

   In the TLS 1.3 key schedule, the quantum_relief extension replaces
   the input from a PSK; the two extensions are not considered useful

Van Rein & Vrancken       Expires July 25, 2020                 [Page 4]

Internet-Draft                   TLS-KDH                    January 2020

   when combined.  In TLS 1.2, a similar result is achieved by enhancing
   the pre-master secret independently of the negotiated cipher suite.

   In addition to Quantum Relief, TLS-KDH can offer authentication based
   on Kerberos tickets.  This introduces new facilities into TLS, such
   as deferred authentication, anonymous realm users and centralised
   facilitation of realm crossover.

3.1.  Injecting Kerberos-derived Entropy

   Whether a Ticket is supplied in the ClientHello or returned by a
   responding peer in the ServerHello, it yields a key only known to the
   two connecting parties.  This key is used in standard Kerberos
   encryption of the concatenated random data from ClientHello and
   ServerHello.  This means that both parties influence the entropy
   gathered and can derive a sequence of bytes that is unknown to anyone
   else.  The output from the encryption operation is plugged into the
   key schedule instead of the PSK input parameter.  This input is
   suited for entropy of arbitrary size.

3.2.  Client-to-Server Flow

   The flow of TLS 1.3 works best when encryption is provided early, and
   authentication is provided late.  These aspects are often combined in
   Kerberos, but KDH splits them to resemble TLS patterns more closely,
   offering separate Kerberos-based protocol fragments for (1)
   additional secret entropy for encryption, (2) client authentication
   through Kerberos Tickets and (3) server authentication through
   Kerberos Tickets.  Only (1) provides Quantum Relief.  The server
   cannot initiate Kerberos, so (3) without (1) is not possible.  When
   (2) is used without (1), Quantum Relief is not achieved.

   The TLS-KDH flow uses ClientHello and ServerHello for a Kerberos-
   protected exchange of entropy, but it completely ignores the client
   identity during this phase.  This allows clients to use an anonymous
   Ticket in the ClientHello message and consider authenticating with an
   identifying Ticket in later client Certificate and CertificateVerify

   Server identity however, is observed in all Tickets, so any use of
   the Ticket's contained key by the server suffices as proof of its
   identity.  This renders the server Certificate and CertificateVerify
   messages redundant if the server accepts the KDH extension,
   especially in TLS 1.3 because the Finished message follows
   immediately.  But redundancy can be a feature; it is certainly
   legitimate to also authenticate the server with an explicit Kerberos
   Ticket, a PKIX certificate or other form.

Van Rein & Vrancken       Expires July 25, 2020                 [Page 5]

Internet-Draft                   TLS-KDH                    January 2020

   When the server desires proof of client identity, it sends a
   CertificateRequest.  KDH introduces a certificate type for a Kerberos
   Ticket, relying on a Kerberos Authenticator as CertificateVerify
   message.  The server is also able to use this to prove being able to
   use a supplied Ticket with its identity.

3.3.  Peer-to-Peer Flow

   TLS-KDH supports the peer-to-peer flow when the QuantumRelief
   extensions specifies "krb5princrealm" as peernametype, followed by a
   TGT from the initiating peer.  This initiating peer MAY use an
   anonymous name for itself in the TGT.

   The responding peer returns in its ServerHello a Ticket based on this
   TGT, obtained through the user-to-user flow of Kerberos.  This return
   Ticket will reverse the client and server role for Kerberos compared
   to TLS, but for peer-to-peer connectivity that is not an issue.  The
   responding peer will authenticate itself to the initiating peer
   through its use of this return Ticket and it can decide whether
   authentication of the initiating client is desired.

   If and when the TLS client authenticates through a Kerberos Ticket,
   it uses the responding peer name as the service name and its own name
   as the client name, in line with the TLS roles for client and server.

4.  New Data Types and Procedures

   The following data structures are introduced to define the Quantum
   Relief mechanism for TLS 1.3 and 1.2.  Additionally, specific values
   and procedures are defined for the TLS-KDH mechanism that implements
   one specific form of quantum relief for TLS.

4.1.  Quantum Relief Extension

   This section defines a new TLS extension called quantum_relief that
   enables quantum relief for TLS as defined in Section 2.  The
   extension is designed such that it can be applied generically.  As a
   concrete quantum relief implementation we herein define how this
   exentions must be used for TLS-KDH [Section 3].  Future mechanisms
   may extend this definition.

   In order to distinguish between different Quantum Relief methods a
   QuantumReliefMethod tag is defined to set KDH aside from possible
   future forms which, to be eligable, MUST assure they meet the
   conditions for providing proper entropy [Section 2].

Van Rein & Vrancken       Expires July 25, 2020                 [Page 6]

Internet-Draft                   TLS-KDH                    January 2020

   enum {
   } QuantumReliefMethod;

   The value "kdh" is used for the TLS-KDH form of Quantum Relief
   defined herein.

   A TLS ClientHello can additionally specify a name for a peer that it
   wants to respond, for which various application-independent forms may
   be anticipated.  This is captured in yet another tag PeerNameType, of
   which only a type for unencrypted Kerberos names is currently defined
   (i.e. krb5princrealm).

   enum {
   } PeerNameType;

   The value "none" is used for client-to-server TLS connections.  The
   value "krb5princrealm" is used in a ClientHello to indicate a
   Kerberos PrincipalName and Realm [Section 5.2.2 of [RFC4120]] for the
   responding peer sought behind the TLS server in peer-to-peer TLS

   The Quantum Relief Extension is now defined as follows:

   struct {
       PeerNameType peernametype;
       select (peernametype) {
           case none:
               /* No peer name type */
           case krb5princrealm:
               /* PrincipalName and Realm, resp. */
               struct {
                   opaque krb5princ<3..1023>;
                   opaque krb5realm<3..1023>;
               } krb5PrincipalRealm;
       QuantumReliefMethod qh_method;
       select (qh_method) {
           case kdh:
               /* Empty, ticket or TGT */
               opaque opt_ticket<0..65535>;
   } QuantumRelief;

Van Rein & Vrancken       Expires July 25, 2020                 [Page 7]

Internet-Draft                   TLS-KDH                    January 2020

   This structure is used as extension_data corresponding to the
   quantum_relief(TBD:QREXTTYPE) extension_type, to occur only during
   ClientHello and ServerHello.

4.2.  Ticket-based Encryption Procedure

   The TLS-KDH messages and cryptographic computations require the use
   of the key concealed in a Ticket to produce a binary object that
   cryptographically binds its input to the key.  It is variably used as
   a source of entropy and as proof, but it is always obtained through a
   standard encryption procedure for Kerberos.

    o = Ticket-Encrypt (t, u, h)

    - Ticket t
    - KeyUsage u
    - Hash h

    - OctetString o

    1. base-key     = t.enc-part.key
    2. specific-key = rfc3961.key-derivation (base-key, u)
    3. init-state   = rfc3961.initial-cipher-state (
                      specific-key, DIRECTION_ENCRYPT)
    4. (state,o)    = rfc3961.encrypt (specific-key, init-state)

   Not shown in the procedure, there is a need to decrypt the enc-part
   of the Ticket before the key concealed in it can be extracted.  This
   is where proof of identity comes into play; only the two parties
   connected by the Ticket should be able to perform this decryption.

   The name prefix "rfc3961" points to the generic descriptions for
   Kerberos key-based procedures [RFC3961] that are implemented with
   various algorithms.  Available algorithms are listed in the IANA
   Registry of Kerberos Parameters.

   The Key Usage values are numbers, for which the following are defined
   by this specification.  Their number ranges are deliberately chosen
   to not clash with those of Kerberos, but otherwise compliant to the
   application range [Section 7.5.1 of [RFC4120]].  The Key Usage values
   are referenced by name elsewhere in this specification.

Van Rein & Vrancken       Expires July 25, 2020                 [Page 8]

Internet-Draft                   TLS-KDH                    January 2020


4.3.  Kerberos Ticket and TGT

   Where this text speaks of a TGT, short for Ticket Granting Ticket, it
   imposes the following requirements to the PrincipalName in the sname
   field of a Ticket:

   o  The name-type is set to NT-SRV-INST or 2

   o  The name-string consists of two component strings

   o  The first name-string component string is the fixed string krbtgt

   To be a TGT, all these requirements MUST be met by a Ticket; a Ticket
   that should be a TGT but does not meet all these conditions is badly
   formed and the recipient MUST respond to it by reporting error
   bad_certificate and closing the connection.

4.4.  Certificate Types

   In order to be able to negotiate Kerberos Tickets as certificate
   types for the Certificate messages, a new certifcate type is
   introduced that can be used in the "client_certificate_type" and
   "server_certificate_type" extensions:

   o  Kerberos Ticket (TBD:KRBTKT-CERTTP)

5.  Changes to TLS Messages and Behaviour

   Although TLS-KDH does not introduce any new messages for TLS, there
   are however a few modifications to the contents or the manner of
   processing of existing messages.  Unless specified otherwise, the
   modifications apply to TLS 1.3 and 1.2 alike.

5.1.  ClientHello

   When this message contains the "quantum_relief" extension, its
   "qh_method" MUST be set to "kdh" under this specification.  Further
   requirements to this extension depend on the pattern of use being
   client-to-server [Section 3.2] or peer-to-peer [Section 3.3].

   To initiate client-to-server traffic, the "peernametype" MUST be set
   to "none", and the "opt_ticket" MUST be a Ticket with the service

Van Rein & Vrancken       Expires July 25, 2020                 [Page 9]

Internet-Draft                   TLS-KDH                    January 2020

   name, host or domain name and Kerberos realm of the addressed
   service.  The client name in the "opt_ticket" MAY be an anonymous
   identity and the server MUST ignore the client identity in the
   "opt_ticket".  When the "server_name" extension is also sent, there
   SHOULD be restrictions enforced by the server on its relation with
   the service name in the "opt_ticket", but this may involve domain-to-
   hostname mappings, for instance through DNS SRV records under DNSSEC

   To initiate peer-to-peer traffic that could be proxied through the
   TLS server to end at a responding peer, the "peernametype" MUST NOT
   be set to "none", and the "opt_ticket" MUST be a TGT for the TLS
   client, suited for the ticket granting service of the TLS server's
   realm; it is permitted for the client to use an anonymous identity in
   this TGT and the server MUST ignore the client identity in the
   "opt_ticket".  When the "peernametype" is set to "krb5princrealm",
   the "krb5princ" and "krb5realm" fields MUST be set to the Kerberos
   PrincipalName and Realm for the desired responding peer.  Future
   extensions may introduce alternative forms of responding peer
   identity and a TLS server SHOULD be open to the general idea of

   When a ClientHello message contains the "quantum_relief" extension,
   it MUST NOT include any references to a PSK.  It MAY independently
   negotiate client and server certificate types [RFC7250] and cipher

5.2.  ServerHello

   When the server accepts the "quantum_relief" extension, it replies
   with its own "quantum_relief" extension and refrains from making any
   PSK references.  This specification defines a response to ClientHello
   extensions with "qh_method" set to "kdh", for which the ServerHello
   extension MUST be set to "kdh" also.

   When the ClientHello extension had its "peernametype" set to "none",
   the ServerHello extension responds to a client-to-server connection
   request.  The TLS data will be procesed on the server and the
   response extension MUST set the "opt_ticket" field to a zero-length
   byte string.

   When the ClientHello extension had its "peernametype" set to another
   value than "none", then the TLS server SHOULD use this to locate a
   responding peer, which may have registered through a mechanism not
   specified herein, and proxy the TLS traffic to this responding peer.
   The TLS server continues to proxy TLS traffic until the connection
   closes.  When such peer-to-peer connectivity is not supported by a
   TLS server or when the peer name could not be resolved or when the

Van Rein & Vrancken       Expires July 25, 2020                [Page 10]

Internet-Draft                   TLS-KDH                    January 2020

   responding peer is unresponsible, the TLS server MUST send a
   handshake_failure alert and close the connection.

   When a responding peer, possibly after registering with a TLS server
   as a recipient for peer-to-peer TLS connections, receives a
   ClientHello with a "quantum_relief" extension with "qh_method" set to
   "kdh" and a "peernametype" and "peername" that it recognises as its
   own and with a TGT in the "opt_ticket" field, it should engage in a
   user-to-user ticket request with the ticket granting service for its
   realm.  It MUST reject the connection if this procedure fails.  When
   a Ticket is obtained, it constructs a ServerHello with a
   "quantum_relief" extension, sets "qh_method" to "kdh" and
   "peernametype" to "none", and "opt_ticket" to the just-obtained
   Ticket.  Furthermore, it continues to act as though the client had
   contacted it directly, while being forgiving to the proxied nature of
   the connection that carries the TLS traffic.  There are no grounds
   for assuming anything about the client identity.

5.3.  Server-sent CertificateRequest

   Since client identity is ignored by the server or responding peer
   during ClientHello and ServerHello and may indeed be toned down to an
   anonymous identity, a server-side requiring to know its client MAY
   send a CertificateRequest in order to verify the client's identity.
   The CertificateRequest MUST be sent when a client_certificate_type
   has been negotiated [RFC7250].  When permitted by the TLS 1.3 client
   with the post_handshake_auth extension, this MAY also be sent at any
   later time.  Under TLS 1.2, TLS renegotiation permits a similar

5.4.  Server-sent Certificate and CertificateVerify

   The Certificate and CertificateVerify messages are not always
   required, because (1) the "quantum_relief" extension captures the
   server identity, and (2) proof thereof is deferred to Finished, which
   under TLS 1.3 is available to the client before it sends the client
   Certificate.  Even in cases when it is not strictly required, a
   server MAY opt for sending server Certificate and CertificateVerify.

   The "server_certificate_type" extension may be used to negotiate any
   supported type for these messages, including the Kerberos Ticket
   certificate type defined herein.  When not negotiated, the default
   type is a PKIX certificate [RFC5280].  Note that a server cannot
   initiate a Kerberos exchange, so a Kerberos type cannot be used when
   the client did not send (or the server rejected) a "quantum_relief"
   extension or when the extension did not provide a Ticket or TGT such
   as it does when the "qh_method" is "kdh".

Van Rein & Vrancken       Expires July 25, 2020                [Page 11]

Internet-Draft                   TLS-KDH                    January 2020

5.5.  Client-sent Certificate and CertificateVerify

   Under TLS 1.3, the server can request client authentication by
   sending a CertificateRequest message.  It is possible for servers to
   do this at any time (provided that the client has sent the
   "post_handshake_auth" extension), and possibly multiple times; TLS
   1.3 even defines how to handle overlapping requests for client

   Clients MAY choose to respond to a CertificateRequest by sending a
   Certificate and CertificateVerify, and the server MAY choose to close
   the connection if the client chooses otherwise.

   The "client_certificate_type" extension may be used to negotiate any
   supported type for these messages, including the Kerberos Ticket
   certificate type defined before.  When not negotiated, the default
   type is X.509.  Note that a client can produce a Kerberos Ticket even
   when no "quantum_relief" extension was negotiated during ClientHello
   and/or ServerHello, or even when another "qh_method" than "kdh" was
   agreed.  However, a client MUST NOT send Certifcate and
   CertificateVerify messages if it did not receive a CertificateRequest
   from the server.

5.6.  Length of Finished

   Under TLS 1.3, the Finished message is as long as the transcript
   hash.  Under TLS 1.2, this is negotiable.  For TLS-KDH under TLS 1.2
   the client MUST request the "verify_data" length within the Finished
   message to be as long as the output length of the hash being used to
   compute it, and the server MUST accept this.

5.7.  Selection of Cipher Suites

   Under TLS 1.3, all current cipher suites incorporate (Elliptic-Curve)
   Diffie-Hellman.  Under TLS 1.2 this is optional.  For TLS-KDH the
   client MUST offer cipher suites that include these forms (i.e.
   ECDHE) of key agreement and the server MUST NOT select a cipher suite
   without any of these forms of key agreement.

5.8.  Tickets and Connection Expiration

   Tickets in Kerberos represent a key-based connection between two
   peers.  The key material in a Ticket is time-limited in the
   understanding that a client can always request a new Ticket if so
   desired.  Expiration of a Ticket SHOULD be matched with a teardown of
   the service.  In terms of TLS-KDH, that means that the connection
   SHOULD NOT exist beyond the life time of a Ticket.  Each side can

Van Rein & Vrancken       Expires July 25, 2020                [Page 12]

Internet-Draft                   TLS-KDH                    January 2020

   independently close down the TLS connection with an
   certificate_expired alert.

   To avoid this, it is possible to request a new client Certificate and
   CertificateVerify through a new CertificateRequest, best sent
   sometime before expiry.  The client then acquires a fresh or
   prolonged Ticket and once exchanged the connection may continue up to
   the timeout of the new Ticket.

   The timeout is updated by every new Ticket supplied in the
   "opt_ticket" field of a "quantum_relief" extension with "qh_method"
   set to "kdh", or by a Certificate of type Kerberos Ticket, provided
   that it is followed by a valid CertificateVerify.

   A server MUST NOT send data over a connection with a timed-out
   Ticket, but SHOULD request a fresh one or disconnect.  A client MUST
   NOT send data over a connection with a timed-out Ticket according to
   its local clock, but it MAY await the arrival a fresh Ticket.  Data
   arriving over a connection with a timed-out Ticket is considered a
   failure to refresh a ticket.  It is a good precaution to request a
   fresh Ticket a few minutes before the active one expires, to
   compensate for clock skew between TLS end points.

   Kerberos supports Tickets with future validity times, intended for
   such things as nightly batch jobs that require authentication.  By
   default, a TLS stack MUST reject such Tickets until they start being
   valid.  It is however possible for applications to override this
   behaviour and treat the connection especially after being informed of
   the future time at which it becomes valid.

6.  Cryptographic Modes

   The introduction of the Quantum Relief extension (in combination with
   TLS-KDH) leads to a few cryptographic changes to the TLS protocol.
   Below, the three modes introduced are discussed independently.
   Separate treatment for TLS 1.3 and 1.2 is only necessary for Quantum
   Relief encryption.  The aspects of client and server authentication
   with Kerberos Tickets use the same data structures and are discussed

6.1.  Quantum Relief for Encryption in TLS 1.3

   Under client-to-server TLS-KDH, the "opt_ticket" in the
   "quantum_relief" extension in the ClientHello is used to supply
   external (quantum proof) key material.  Under peer-to-peer TLS-KDH,
   the TGT in the "opt_ticket" supplies no shared key material to the
   client and server (or responding peer), but the ServerHello returns a

Van Rein & Vrancken       Expires July 25, 2020                [Page 13]

Internet-Draft                   TLS-KDH                    January 2020

   "quantum_relief" extension with an "opt_ticket" field holding a
   Ticket that does supply a shared key to use.

   This key is used to compute Ticket-Encrypt (opt_ticket, usage,
   ClientHello.random || ServerHello.random) where || signifies
   concatenation, and usage is either KEYUSAGE_TLSKDH_CLIENT_QR for a
   Ticket supplied by the client, or KEYUSAGE_TLSKDH_SERVER_QR for a
   Ticket supplied by the server side (or responding peer).  The output
   of this computation is provided instead of the PSK on the left of the
   Key Schedule for TLS 1.3 [page 93 of [RFC8446]].  Note how the
   ServerHello is involved in this computation, and not just the
   ClientHello; had PSK facilities been used, then this seeding would
   have arrived too late to provide the binder_key,
   client_early_traffic_secret and early_exporter_master_key.  But
   replacing the locally oriented PSK mechanism with TLS-KDH, means that
   there is no facility for early data or other PSK facilities, so these
   keys need not be computed.

   Other "qh_method" values than "kdh" are likely to come up with other
   computations.  There may be some that prefer to influence only the
   master key by replacing the 0 value for key input as it is shown in
   the TLS 1.3 key schedule.

6.2.  Quantum Relief for Encryption in TLS 1.2

   TLS 1.2 does not offer any form of encryption during the handshake,
   so Quantum Relief for TLS 1.2 can only be used to strengthen the
   Master Secret.  When the "quantum_relief" extension with the "kdh"
   method is accepted by the server, a Ticket is available while forming
   the ServerHello; it is in the ClientHello for client-to-server mode
   and in the ServerHello for peer-to-peer mode.  Call this Ticket qrt
   and use it to compute Ticket-Encrypt (qrt,
   KEYUSAGE_TLS12KDH_PREMASTER_QH, ClientHello.random ||
   ServerHello.random), where || denotes concatenation.  The output of
   this procedure is a octet string which is prepended to what the
   cipher-suite defines as its pre-master secret.  This prepended form
   is then used instead of the normal pre-master secret during the
   computation of the master key.

6.3.  Kerberos Ticket as Certificate and CertificateVerify

   Kerberos Tickets(TBD:KRBTKT-CERTTP) can be negotiated independently
   as client_certificate_type and server_certificate_type [RFC7250],
   though the latter is impossible without a client certificate; in TLS-
   KDH, a client certificate is available when the server accepts the
   client's quantum_relief extension.

Van Rein & Vrancken       Expires July 25, 2020                [Page 14]

Internet-Draft                   TLS-KDH                    January 2020

   The contents of the Certificate message when the certificate type is
   negotiated as this "Kerberos" certificate type is a Kerberos Ticket

   The contents of the corresponding CertificateVerify message uses this
   Ticket k5crt to compute Ticket-Encrypt (k5crt, KEYUSAGE_CLIENT_VFY,
   th) for a client CertificateVerify message or Ticket-Encrypt (k5crt,
   KEYUSAGE_SERVER_VFY, th) for a server CertificateVerify message,
   where th is the customary hash up to and including the preceding
   Certificate message.  For TLS 1.3, this customary hash uses the
   transcript hash; for TLS 1.2, the hash algorithm must match the
   Certificate signing algorithm, which in case of a Kerberos Ticket
   means its MAC hashing algorithm without reductions in the size of the
   hash output.

7.  KDH-Only Application Profile

   The default use of TLS involves authentication based on X.509
   certificates.  In some scenarios such a PKI is not available or not
   desirable.  For this reason, the remainder of this section defines an
   alternative, KDH-Only Application Profile as minimally being TLS-KDH

   TLS-KDH-compliant applications MUST implement the
   TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
   TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
   [RFC8439] cipher suites.

   TLS-KDH-compliant applications MUST support the Kerberos Ticket
   certificate type.  They also MUST treat X.509 as the default
   certificate type, but they MAY refuse any attempt to use it, either
   by negotiating an explicit alternative or failing to negotiate an

   TLS-KDH-compliant applications MUST support key exchanges with
   secp256r1 (NIST P-256) and SHOULD support key exchanges with X25519

   TLS-KDH-compliant applications MUST support the quantum_relief TLS
   extension, for which the qh_method value "kdh" MUST be supported, and
   the peernametype value "none" MUST and "krb5princrealm" SHOULD be

8.  Security Considerations

   Quantum Relief is an alternative to the PSK mechanism, which may have
   similar benefits for local setups, but is not subject of discussion
   here.  The loss of PSK facilities means that no Early Data can be

Van Rein & Vrancken       Expires July 25, 2020                [Page 15]

Internet-Draft                   TLS-KDH                    January 2020

   sent, which can be resolved by sending the same data later.  It is a
   loss of efficiency, but not of security.

8.1.  Encryption

   To establish that encryption has successfully been established, a
   party must validate encrypted data received from the other.  This is
   at least the case when a proper Finished message arrives, which
   provides ample entropy to be certain, incorporating the identities
   exchanged throughout the handshake.

   In TLS 1.3, the parties may send encrypted data which may provide
   ample entropy as well.  The transcript hash does not include the
   entropy derived with the Quantum Relief extension, and so
   authentication cannot be used as proof of having established
   encryption unless it is as a provider of verifiable entropy that is
   wrapped in handshake encryption.

   The late establishment of encryption has an impact on the privacy of
   client identity.  This identity is unprotected in TLS 1.2, but under
   TLS 1.3 its privacy is protected with encryption.  To ensure that the
   right party is communicating remotely, the Finished message SHOULD be
   processed before sending the client's Certificate.

8.2.  Server Authentication

   The identity of the server under generic Quantum Relief needs to wait
   for the arrival of the server's Certificate and CertificateVery
   messages.  Specifically for TLS-KDH, the ability to decrypt a Ticket
   (for the client-to-server flow) or to produce a Ticket from a TGT
   (for the peer-to-peer flow) provides the same proof.  Clients MAY use
   this, but MUST also validate a Certificate and CertificateVerify if
   the server sends them.

   Under TLS-KDH, the server produces a Ticket with identities for both
   client and server.  The client MUST be able to extract the secret
   from the Ticket, as an assurance that it is the designated receiver
   for this identity claim.  The verification of the CertificateVerify
   assures this, as well as the binding to the TLS flow through the
   transcript hash.

8.3.  Client Authentication

   The server MUST NOT process any client identity in the QuantumRelief
   extension, because that may be either an anonymous identity or a
   pseudonym, to avoid public visibility.  When client identity is
   needed by the server, it MUST ask for it with a CertificateRequest.

Van Rein & Vrancken       Expires July 25, 2020                [Page 16]

Internet-Draft                   TLS-KDH                    January 2020

   The client Certificate and CertificateVerify provide the proper
   identity for the client, which MAY differ from any identity passed

   Under TLS-KDH, the client produces a Ticket with identities for both
   client and server.  The server MUST be able to extract the secret
   from the Ticket, as an assurance that it is the designated receiver
   for this identity claim.  The verification of the CertificateVerify
   assures this, as well as the binding to the TLS flow through the
   transcript hash.

9.  IANA Considerations

   IANA adds the following TLS ExtensionType Value as part of their
   Transport Layer Security Extensions registry:

   Value         Extension Name  TLS 1.3  Recommended  Reference
   TBD:QREXTTYP  quantum_relief  CH, SH   Y            TBD:ThisSpec

   IANA adds the following TLS Certificate Type as part of their
   Transport Layer Security Extensions registry:

   Value              Name             Recommended  Reference
   TBD:KRBTKT-CERTTP  Kerberos Ticket  Y            TBD:ThisSpec

   IANA creates a registry for the QuantumReliefMethod in the TBD: TLS
   Extensions registry, with the following initial entries and new
   entries to be assigned under a Specification Required policy.

   Value        Method                    Reference
   -----------  ------------------------  ------------
   0            kdh                       TBD:ThisSpec
   1-65281      Unassigned
   65282-65535  Reserved for Private Use  TBD:ThisSpec

   IANA creates a registry for the PeerNameType in the TBD: TLS
   Extensions registry, with the following initial entries and new
   entries to be assigned under a Specification Required policy.

   Value        Name Type                 Reference
   -----------  ------------------------  ------------
   0            none                      TBD:ThisSpec
   1            krb5princrealm            TBD:ThisSpec
   2-65281      Unassigned
   65282-65535  Reserved for Private Use  TBD:ThisSpec

Van Rein & Vrancken       Expires July 25, 2020                [Page 17]

Internet-Draft                   TLS-KDH                    January 2020

10.  Normative References

   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
              Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
              2005, <https://www.rfc-editor.org/info/rfc3961>.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              DOI 10.17487/RFC4120, July 2005,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,

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

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,

Appendix A.  Acknowledgements

   This specification could not have matured without the insights of
   various commenters.  In order of appearance, we owe thanks to Simo
   Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos
   Mavragiannopoulos, Kenneth Raeburn.

   Part of this work was conducted under a grant from the programme
   "[veilig] door innovatie" from the government of the Netherlands.  It
   has also been liberally supported by the NLnet Foundation.

Authors' Addresses

Van Rein & Vrancken       Expires July 25, 2020                [Page 18]

Internet-Draft                   TLS-KDH                    January 2020

   Rick van Rein
   Haarlebrink 5
   Enschede, Overijssel  7544 WP
   The Netherlands

   Email: rick@openfortress.nl

   Tom Vrancken
   Eindhoven, Noord-Brabant  TBD:WHICH
   The Netherlands

   Email: tom.vrancken@arpa2.org

Van Rein & Vrancken       Expires July 25, 2020                [Page 19]