Internet DRAFT - draft-vanrein-tls-kdh
draft-vanrein-tls-kdh
Network Working Group R. Van Rein
Internet-Draft T. Vrancken
Intended status: Informational InternetWide.org
Expires: 24 April 2023 21 October 2022
Quantum Relief with TLS and Kerberos
draft-vanrein-tls-kdh-08
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 24 April 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Van Rein & Vrancken Expires 24 April 2023 [Page 1]
Internet-Draft TLS-KDH October 2022
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 include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . 8
4.2. Peer-to-Peer Flow . . . . . . . . . . . . . . . . . . . . 8
4.3. Injecting Kerberos-derived Entropy . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 20
7.3. Client Authentication . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9. Normative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Van Rein & Vrancken Expires 24 April 2023 [Page 2]
Internet-Draft TLS-KDH October 2022
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.
Van Rein & Vrancken Expires 24 April 2023 [Page 3]
Internet-Draft TLS-KDH October 2022
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 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:
* The amount of entropy must on its own suffice for the desired
security level of the TLS connection.
* 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).
* 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.
Van Rein & Vrancken Expires 24 April 2023 [Page 4]
Internet-Draft TLS-KDH October 2022
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.
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
* Negotiate a concrete Quantum Relief mechanism / method
* Initiate / execute the negotiated method
* 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;
Van Rein & Vrancken Expires 24 April 2023 [Page 5]
Internet-Draft TLS-KDH October 2022
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:
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
Van Rein & Vrancken Expires 24 April 2023 [Page 6]
Internet-Draft TLS-KDH October 2022
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.
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:
* An alternative to PKIX credentials in TLS [RFC5280]
* 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.
Van Rein & Vrancken Expires 24 April 2023 [Page 7]
Internet-Draft TLS-KDH October 2022
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.
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.
Van Rein & Vrancken Expires 24 April 2023 [Page 8]
Internet-Draft TLS-KDH October 2022
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
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.
Van Rein & Vrancken Expires 24 April 2023 [Page 9]
Internet-Draft TLS-KDH October 2022
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:
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 24 April 2023 [Page 10]
Internet-Draft TLS-KDH October 2022
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:
* The name-type is set to NT-SRV-INST or 2
Van Rein & Vrancken Expires 24 April 2023 [Page 11]
Internet-Draft TLS-KDH October 2022
* The name-string consists of two component strings
* 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:
* 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
Van Rein & Vrancken Expires 24 April 2023 [Page 12]
Internet-Draft TLS-KDH October 2022
realm; it is permitted for the client to use an anonymous identity in
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 24 April 2023 [Page 13]
Internet-Draft TLS-KDH October 2022
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 24 April 2023 [Page 14]
Internet-Draft TLS-KDH October 2022
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 24 April 2023 [Page 15]
Internet-Draft TLS-KDH October 2022
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 24 April 2023 [Page 16]
Internet-Draft TLS-KDH October 2022
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)
Van Rein & Vrancken Expires 24 April 2023 [Page 17]
Internet-Draft TLS-KDH October 2022
where || denotes concatenation. The output of this procedure is an
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.
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.
Van Rein & Vrancken Expires 24 April 2023 [Page 18]
Internet-Draft TLS-KDH October 2022
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
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.
Van Rein & Vrancken Expires 24 April 2023 [Page 19]
Internet-Draft TLS-KDH October 2022
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
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
Van Rein & Vrancken Expires 24 April 2023 [Page 20]
Internet-Draft TLS-KDH October 2022
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 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>.
Van Rein & Vrancken Expires 24 April 2023 [Page 21]
Internet-Draft TLS-KDH October 2022
[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>.
[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
Email: rick@openfortress.nl
Tom Vrancken
InternetWide.org
Imstenrade 24
Eindhoven
Email: tom.vrancken@arpa2.org
Van Rein & Vrancken Expires 24 April 2023 [Page 22]
