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

Versions: 00 01 02 03 04 05 06 07                                       
Network Working Group                                        R. Van Rein
Internet-Draft                                               T. Vrancken
Intended status: Informational                          InternetWide.org
Expires: December 7, 2021                                    Jun 5, 2021


                  Quantum Relief with TLS and Kerberos
                        draft-vanrein-tls-kdh-07

Abstract

   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 time 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 December 7, 2021.

Copyright Notice

   Copyright (c) 2021 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 December 7, 2021                [Page 1]


Internet-Draft                   TLS-KDH                        Jun 2021


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Quantum Relief as a General Mechanism . . . . . . . . . . . .   3
     2.1.  Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . .   4
   3.  The quantum_relief TLS extension  . . . . . . . . . . . . . .   5
     3.1.  Extension data structures . . . . . . . . . . . . . . . .   5
     3.2.  Extension behavior  . . . . . . . . . . . . . . . . . . .   6
   4.  TLS-KDH for Quantum Relief through Kerberos . . . . . . . . .   7
     4.1.  Client-to-Server Flow . . . . . . . . . . . . . . . . . .   7
     4.2.  Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Injecting Kerberos-derived Entropy  . . . . . . . . . . .   8
     4.4.  New Data Types and Procedures . . . . . . . . . . . . . .   9
       4.4.1.  The quantum_relief KDH method . . . . . . . . . . . .   9
       4.4.2.  Ticket-based Encryption Procedure . . . . . . . . . .  10
       4.4.3.  Kerberos Ticket and TGT . . . . . . . . . . . . . . .  11
       4.4.4.  Certificate Types . . . . . . . . . . . . . . . . . .  12
     4.5.  Changes to TLS Messages and Behaviour . . . . . . . . . .  12
       4.5.1.  ClientHello . . . . . . . . . . . . . . . . . . . . .  12
       4.5.2.  ServerHello . . . . . . . . . . . . . . . . . . . . .  13
       4.5.3.  Server-sent CertificateRequest  . . . . . . . . . . .  14
       4.5.4.  Server-sent Certificate and CertificateVerify . . . .  14
       4.5.5.  Client-sent Certificate and CertificateVerify . . . .  15
       4.5.6.  Length of Finished  . . . . . . . . . . . . . . . . .  15
       4.5.7.  Selection of Cipher Suites  . . . . . . . . . . . . .  15
       4.5.8.  Tickets and Connection Expiration . . . . . . . . . .  16
   5.  Cryptographic Modes . . . . . . . . . . . . . . . . . . . . .  16
     5.1.  Quantum Relief for Encryption in TLS 1.3  . . . . . . . .  17
     5.2.  Quantum Relief for Encryption in TLS 1.2  . . . . . . . .  17
     5.3.  Kerberos Ticket as Certificate and CertificateVerify  . .  18
   6.  KDH-Only Application Profile  . . . . . . . . . . . . . . . .  18
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     7.1.  Encryption  . . . . . . . . . . . . . . . . . . . . . . .  19
     7.2.  Server Authentication . . . . . . . . . . . . . . . . . .  19
     7.3.  Client Authentication . . . . . . . . . . . . . . . . . .  20
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  21
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22








Van Rein & Vrancken     Expires December 7, 2021                [Page 2]


Internet-Draft                   TLS-KDH                        Jun 2021


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
   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 TLS extension called "quantum_relief"
   [Section 3] that facilitates mixing in secret entropy from another
   source into the TLS key computations.  Additionally, we define a
   concrete mechanism that provides (1) a source of secret entropy and
   (2) an alternative authentication mechanism.  This 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 [Section 4].  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, into the key schedule.
   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



Van Rein & Vrancken     Expires December 7, 2021                [Page 3]


Internet-Draft                   TLS-KDH                        Jun 2021


   for a PSK however, will have to be uncovered separately, and this
   will not be possible in the general case.

   This specification exploits this entropy insertion possibilities by
   defining a generic TLS extension called "quantum_relief".  The
   "quantum_relief" extension 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.  While enabling relief against quantum computer attacks, this
   mechanism, however, sacrifices support for 0-RTT data in TLS 1.3.
   For TLS 1.2, an extension to the computation of the master secret
   inserts the extra entropy.

   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 desired
      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 designated peer.

   Without documenting it here, the TLS server is assumed to have some
   method of designating a peer with this information, and will proxies
   the TLS connection to its peer.  The TLS server is not involved in
   cryptographic computations for the relayed TLS connection; its only
   task is to relay TLS data from the client to the designated peer and
   vice versa.





Van Rein & Vrancken     Expires December 7, 2021                [Page 4]


Internet-Draft                   TLS-KDH                        Jun 2021


3.  The quantum_relief TLS extension

   This section defines a new TLS extension called "quantum_relief" that
   enables relief against quantum computer attacks for TLS as defined in
   Section 2.  The extension is designed such that it can be applied
   generically.  Its purpose is to

   o  Negotiate a concrete Quantum Relief mechanism / method

   o  Initiate / execute the negotiated method

   o  Inject the secret entropy, which is produced by the negotiated
      Quantum Relief method, into the TLS key schedule

   A concrete Quantum Relief method that leverages this "quantum_relief"
   extension is TLS-KDH, which is defined in Section 4.  Future
   mechanisms may be added by extending the data structures defined for
   the "quantum_relief" extension.

3.1.  Extension data structures

   In order to distinguish between different Quantum Relief methods, a
   QuantumReliefMethod tag is defined.  Every (future) method must be
   assigned a unique identifier in order to be able to deterministically
   negotiate a Quantum Relief method between client and server.

   enum {
       none(0),
       (65535)
   } QuantumReliefMethod;

   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 called
   PeerNameType.

   enum {
       none(0),
       (65535)
   } PeerNameType;

   The value "none" in both tags is defined as default value and
   signifies no use of a Quantum Relief method or alternative peer name
   respectively.  They are used for regular client-to-server TLS
   connections.  Additional values and their corresponding data
   structures may be defined by concrete Quantum Relief mechanisms.

   The "quantum_relief" extension structure is now defined as follows:



Van Rein & Vrancken     Expires December 7, 2021                [Page 5]


Internet-Draft                   TLS-KDH                        Jun 2021


   struct {
       QuantumReliefMethod qr_method;
       select (qr_method) {
           case none:
               /* Do not send this extension */
               Empty;
       }
       PeerNameType peernametype;
       select (peernametype) {
           case none:
               /* No peer name type */
               Empty;
       }
   } QuantumRelief;

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

3.2.  Extension behavior

   When negotiating a Quantum Relief method and a peer name type, the
   following rules must be followed.

   A TLS client MUST only advertise a Quantum Relief method that it is
   capable of and willing to perform.  The default Quantum Relief method
   is none(0) and in that case the "quantum_relief" extension MUST NOT
   be sent.  In case another Quantum Relief method is set, the client
   SHOULD wait with the execution of this method until it receives a
   method confirmation from the server in the ServerHello.  In case the
   server sends no confirmation or replies with a different Quantum
   Relief method than was advertised, no Quantum Relief method MUST be
   executed.  In that case, the client MAY decide to either continue or
   abort the handshake.

   A TLS server MUST only accept a Quantum Relief method that it is
   capable of and willing to perform.  In case a server accepts the
   method that was advertised by the client, it MAY initiate the
   execution of this method.  When it does, it MUST confirm this method
   to the client in its ServerHello message.  Furthermore, it MUST NOT
   make any PSK references.  In case a server does not accept the method
   that was advertised by the client, it MUST refrain from sending this
   extension.

   A TLS client MUST only set a peer name type and corresponding peer
   name specification if the client wishes to address a peer other than
   the TLS server.  How this peer name should be interpreted and
   processed is up to the negotiated Quantum Relief method.



Van Rein & Vrancken     Expires December 7, 2021                [Page 6]


Internet-Draft                   TLS-KDH                        Jun 2021


   A TLS server MUST confirm the peer name type to the client in its
   ServerHello if the server is able to, and going to process the
   provided peer name.  A server MUST never set a peer name
   specification itself.

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

4.  TLS-KDH for Quantum Relief through Kerberos

   This section defines a mechanism called TLS-KDH.  TLS-KDH is a mode
   of using TLS that was designed to provide two things:

   o  An alternative to PKIX credentials in TLS [RFC5280]

   o  Quantum Relief for TLS connections

   The key derivation mechanisms in Kerberos are helpful in a Quantum
   Relief mechanism; locally controlled secrets are gradually adapted to
   more specific uses in a non-reversible manner.  The various uses
   cannot use one token to derive another, whether it is for TLS-KDH or
   another secure service.

   To achieve Quantum Relief, (external) secret entropy needs to be
   generated and inserted into the TLS key schedule.  In the TLS 1.3 key
   schedule, the "quantum_relief" extension inserts this entropy at the
   position where normally the PSK is input; The two extensions (i.e.,
   "quantum_relief" and PSK) are not considered useful 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.

4.1.  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.  When (2) is
   used without (1), Quantum Relief is not achieved.



Van Rein & Vrancken     Expires December 7, 2021                [Page 7]


Internet-Draft                   TLS-KDH                        Jun 2021


   The TLS-KDH mechanism 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 messages.

   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 method for
   authentication, 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.

   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.

4.2.  Peer-to-Peer Flow

   TLS-KDH also supports a peer-to-peer flow.  Here, instead of sending
   a regular Ticket, a client sends a Ticket Granting Ticket (TGT) to
   the server.  The server then acts as a proxy that relays TLS traffic
   to the destined peer and back.  The initiating peer (i.e., the
   client) MAY use an anonymous name for itself in the TGT.

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

   If the TLS client authenticates through a Kerberos Ticket, it uses
   the designated 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.3.  Injecting Kerberos-derived Entropy

   Whether a Ticket is supplied in the ClientHello or returned by a
   designated peer in the ServerHello, it yields a key only known to the
   two connecting parties.  This key is applied to the concatenated



Van Rein & Vrancken     Expires December 7, 2021                [Page 8]


Internet-Draft                   TLS-KDH                        Jun 2021


   random data from ClientHello and ServerHello to derive a new secret.
   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.

4.4.  New Data Types and Procedures

   This section describes the data structures and procedures that are
   introduced by the TLS-KDH mechanism.

4.4.1.  The quantum_relief KDH method

   TLS-KDH defines a concrete Quantum Relief method for the
   "quantum_relief" extension that is defined in Section 3.  The
   necessary data type extensions are defined here.

   enum {
       none(0),
       kdh(1),
       (65535)
   } QuantumReliefMethod;

   The QuantumReliefMethod type is extended with the value "kdh" that is
   used to identify the TLS-KDH method of Quantum Relief defined herein.

   enum {
       none(0),
       krb5princrealm(1),
       (65535)
   } PeerNameType;

   In these two types, the value "none" is used for regular 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 designated peer sought behind
   the TLS server in peer-to-peer TLS connections.

   The "quantum_relief" extension with support for the KDH method is now
   defined as follows:










Van Rein & Vrancken     Expires December 7, 2021                [Page 9]


Internet-Draft                   TLS-KDH                        Jun 2021


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

4.4.2.  Ticket-based Encryption Procedure

   This section describes the procedure for encryption based on Kerberos
   primitives.  The procedure is referenced in other sections, for
   proofs and as a source of entropy.

   The TLS-KDH messages and cryptographic computations require Kerberos
   through their use of the key concealed in a Ticket.  The defined
   function below produces a binary object that cryptographically binds
   its input to the key.


















Van Rein & Vrancken     Expires December 7, 2021               [Page 10]


Internet-Draft                   TLS-KDH                        Jun 2021


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

   Input:
    - Ticket t
    - KeyUsage u
    - Hash h

   Output:
    - OctetString o

   Steps:
    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.

   2008 = KEYUSAGE_TLS12KDH_PREMASTER_QR
   2018 = KEYUSAGE_TLSKDH_CLIENT_QR
   2019 = KEYUSAGE_TLSKDH_SERVER_QR
   2020 = KEYUSAGE_TLSKDH_SERVER_VFY
   2021 = KEYUSAGE_TLSKDH_CLIENT_VFY

4.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
   [Section 5.2.2 of [RFC4120]] in the sname field of a Ticket:

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




Van Rein & Vrancken     Expires December 7, 2021               [Page 11]


Internet-Draft                   TLS-KDH                        Jun 2021


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

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

4.5.1.  ClientHello

   When this message contains the "quantum_relief" extension, its
   "qr_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 4.1] or peer-to-peer [Section 4.2].

   To initiate client-to-server traffic, the "peernametype" MUST be set
   to "none", and the "opt_ticket" MUST be a Ticket with the service
   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
   protection.

   To initiate peer-to-peer traffic that could be proxied through the
   TLS server to end at a designated 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



Van Rein & Vrancken     Expires December 7, 2021               [Page 12]


Internet-Draft                   TLS-KDH                        Jun 2021


   this TGT and both the server and the designated peer 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 designated peer.
   Future extensions may introduce alternative forms of designated peer
   identities and a TLS server SHOULD be open to the general idea of
   identity.

4.5.2.  ServerHello

   This specification defines a response to ClientHello extensions with
   "qr_method" set to "kdh", for which the accepting ServerHello
   extension MUST also be set to "kdh".

   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 processed on the server and the
   response extension MUST set the "opt_ticket" field to a zero-length
   byte string representing an empty ticket field (i.e., no ticket).

   When the ClientHello extension had its "peernametype" set to another
   value than "none", then the TLS server SHOULD use this to locate a
   designated peer, which may have registered through a mechanism not
   specified herein, and proxy the TLS traffic to this designated 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 to a
   designated peer or when the designated peer is unresponsible, the TLS
   server MUST send a handshake_failure alert and close the connection.

   When a designated peer, possibly after out-of-band registration with
   a TLS server as a recipient for peer-to-peer TLS connections,
   receives a ClientHello with a "quantum_relief" extension with
   "qr_method" set to "kdh", 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 "qr_method" to
   "kdh", "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.







Van Rein & Vrancken     Expires December 7, 2021               [Page 13]


Internet-Draft                   TLS-KDH                        Jun 2021


4.5.3.  Server-sent CertificateRequest

   Since client identity is ignored by the server or designated 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.

   When using KDH without server certificate, the server MUST send a
   CertificateRequest with which it requests a Kerberos Ticket from the
   client in order to mutually authenticate each other.  If the client
   does not provide such a ticket, authentication can not take place and
   the handshake MUST be aborted.  Note that the client is still allowed
   to provide an anonymous ticket.  This may, however, result in
   authentication being rejected by the server.

   When using KDH with server certificate, the server SHOULD send a
   CertificateRequest to request for a ticket with which the (regular)
   server authentication (e.g., X.509) can be enhanced.  The client MAY
   decline this offer and it is up to the server whether to accept this
   or not.

   In order to be able to request a Kerberos Ticket during the
   handshake, the Kerberos Ticket (TBD:KRBTKT-CERTTP) certificate type
   must be negotiated via the client_certificate_type extension
   [RFC7250].  If a client_certificate_type was negotiated then
   CertificateRequest MUST be sent.  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 facility.

4.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 "qr_method" is "kdh".




Van Rein & Vrancken     Expires December 7, 2021               [Page 14]


Internet-Draft                   TLS-KDH                        Jun 2021


4.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
   authentication.

   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.  When the server does
   not supply a server certificate, a client Certificate message is
   mandatory in order for both parties to authenticate.  If the client
   does not provide a ticket via a Certificate message then the server
   MUST abort the handshake.

   Note that under TLS-KDH a CertificateVerify message consists of a
   Kerberos Authenticator [Section 5.5.1 of [RFC4120]].  The
   Authenticator serves as the Kerberos equivalent of a digital
   signature.

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

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

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




Van Rein & Vrancken     Expires December 7, 2021               [Page 15]


Internet-Draft                   TLS-KDH                        Jun 2021


4.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
   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 "qr_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 of a fresh Ticket (from
   its KDC).  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 endpoints.

   Kerberos supports Tickets with future validity times, intended for
   such things as nightly batch jobs that require authentication.  By
   default, a TLS stack should reject such Tickets until they start
   being valid.  Specific applications may however be aware of this
   enhancement and deliberately override this default behaviour; an
   example would be an application that schedules such nightly jobs.

5.  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
   together.




Van Rein & Vrancken     Expires December 7, 2021               [Page 16]


Internet-Draft                   TLS-KDH                        Jun 2021


5.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 designated peer), but the ServerHello returns a
   "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 designated 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 "qr_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.

5.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 an
   octet string which is prepended to what the cipher-suite defines as



Van Rein & Vrancken     Expires December 7, 2021               [Page 17]


Internet-Draft                   TLS-KDH                        Jun 2021


   its pre-master secret.  This prepended form is then used instead of
   the normal pre-master secret during the computation of the master
   key.

5.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]; in
   TLS-KDH, a client certificate is available when the server accepts
   the client's "quantum_relief" extension with method "kdh".

   The contents of the Certificate message when the certificate type is
   negotiated as this "Kerberos" certificate type is a Kerberos Ticket
   [Section 5.3 of [RFC4120]] in the customary DER encoding.

   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
   transcript hash up to and including the preceding Certificate
   message.  For TLS 1.3, this hash algorithm equals the transcript hash
   algorithm; 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.

6.  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
   compliant.

   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




Van Rein & Vrancken     Expires December 7, 2021               [Page 18]


Internet-Draft                   TLS-KDH                        Jun 2021


   by negotiating an explicit alternative or failing to negotiate an
   alternative.

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

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

7.  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
   sent, which can be resolved by sending the same data later.  It is a
   loss of efficiency, but not of security.

7.1.  Encryption

   To verify 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.

7.2.  Server Authentication

   The identity of the server under generic Quantum Relief needs to wait
   for the arrival of the server's Certificate and CertificateVerify
   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



Van Rein & Vrancken     Expires December 7, 2021               [Page 19]


Internet-Draft                   TLS-KDH                        Jun 2021


   trust this to validate server identity, but MUST also validate a
   Certificate and CertificateVerify if the server sends them.

   Under the peer-to-peer flow, the designated peer produces a Ticket
   with Kerberos roles reversed relative to TLS roles.  The Ticket
   produced mentions the designated peer as a Kerberos client to the
   service of the TGT-sending party, which is the TLS client.  This is
   neither a problem to the peer-to-peer flow of TLS-KDH, nor to the
   user-to-user mechanism [Section 3.7 of [RFC4120]] of Kerberos.  The
   TLS 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.

7.3.  Client Authentication

   The server MUST NOT process any client identity in the Quantum Relief
   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.

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

   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.

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






Van Rein & Vrancken     Expires December 7, 2021               [Page 20]


Internet-Draft                   TLS-KDH                        Jun 2021


   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            none                      TBD:ThisSpec
   1            kdh                       TBD:ThisSpec
   2-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

9.  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,
              <https://www.rfc-editor.org/info/rfc4120>.

   [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,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
              Key Derivation Function (HKDF)", RFC 5869,
              DOI 10.17487/RFC5869, May 2010,
              <https://www.rfc-editor.org/info/rfc5869>.








Van Rein & Vrancken     Expires December 7, 2021               [Page 21]


Internet-Draft                   TLS-KDH                        Jun 2021


   [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,
              <https://www.rfc-editor.org/info/rfc8446>.

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

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

   Email: rick@openfortress.nl


   Tom Vrancken
   InternetWide.org
   Imstenrade 24
   Eindhoven, Noord-Brabant  5655 BN
   The Netherlands

   Email: tom.vrancken@arpa2.org












Van Rein & Vrancken     Expires December 7, 2021               [Page 22]