< draft-vanrein-tls-kdh-04.txt   draft-vanrein-tls-kdh-05.txt >
Network Working Group R. Van Rein Network Working Group R. Van Rein
Internet-Draft ARPA2.net Internet-Draft T. Vrancken
Intended status: Standards Track June 13, 2016 Intended status: Standards Track ARPA2.net
Expires: December 15, 2016 Expires: February 17, 2020 August 16, 2019
TLS-KDH: Kerberos + Diffie-Hellman in TLS Quantum Relief for TLS with Kerberos
draft-vanrein-tls-kdh-04 draft-vanrein-tls-kdh-05
Abstract Abstract
This specification defines a TLS message flow with Kerberos-based This specification adds Kerberos to the TLS protocol, both as a
(mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to method of authentication and to insert entropy into the key schedule
achieve Forward Secrecy for the session. from a source that does not start in public key cryptography.
TODO: Deprecates RFC2712 This brings relief from attacks by quantum computers, and that is
specified as part of a more general framework, to make it easier for
other technologies to achieve similar benefits.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2016. This Internet-Draft will expire on February 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Extending Kerberos to support TLS . . . . . . . . . . . . . . 4 2. Quantum Relief from Pre-Shared Keys . . . . . . . . . . . . . 3
2.1. Checksum Types for use with TLS . . . . . . . . . . . . . 4 3. The Design of TLS-KDH . . . . . . . . . . . . . . . . . . . . 4
2.2. Authenticators as Signatures . . . . . . . . . . . . . . 4 4. New Data Structures and Procedures . . . . . . . . . . . . . 5
2.3. Tickets in the TLS Certificate flow . . . . . . . . . . . 5 4.1. Extension quantum_relief . . . . . . . . . . . . . . . . 5
2.4. AuthorizationData for Backend Services . . . . . . . . . 6 4.2. Ticket-based Encryption Procedure . . . . . . . . . . . . 7
3. Extending TLS to support Kerberos . . . . . . . . . . . . . . 7 4.3. Kerberos Ticket and TGT . . . . . . . . . . . . . . . . . 8
3.1. Conceptual Data Model Extensions . . . . . . . . . . . . 7 5. Changes to TLS Messages . . . . . . . . . . . . . . . . . . . 8
3.2. Certificate Type KerberosTicket . . . . . . . . . . . . . 7 5.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 7 5.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. KDH-only CipherSuites . . . . . . . . . . . . . . . . . . 8 5.3. Server-sent VerifyRequest . . . . . . . . . . . . . . . . 10
3.5. TicketRequestFlags Extension . . . . . . . . . . . . . . 9 5.4. Server-sent Certificate and CertificateVerify . . . . . . 10
3.6. TLS Connection Expiration . . . . . . . . . . . . . . . . 11 5.5. Client-sent Certificate and CertificateVerify . . . . . . 10
3.7. Interaction with Applications . . . . . . . . . . . . . . 11 5.6. Length of Finished . . . . . . . . . . . . . . . . . . . 11
3.8. Kerberos-Only TLS Application Profile . . . . . . . . . . 11 5.7. Selection of Cipher Suites . . . . . . . . . . . . . . . 11
4. The Message Flow of TLS-KDH . . . . . . . . . . . . . . . . . 12 5.8. Tickets and Connection Timing . . . . . . . . . . . . . . 11
4.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 13 6. Cryptographic Updates . . . . . . . . . . . . . . . . . . . . 12
4.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Quantum Relief for Encryption in TLS 1.3 . . . . . . . . 12
4.3. Server Certificate . . . . . . . . . . . . . . . . . . . 14 6.2. Quantum Relief for Encryption in TLS 1.2 . . . . . . . . 12
4.4. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 14 6.3. Kerberos Ticket as Certificate and CertificateVerify . . 13
4.5. CertificateRequest . . . . . . . . . . . . . . . . . . . 14 7. KDH-Only Application Profile . . . . . . . . . . . . . . . . 13
4.6. Client Certificate . . . . . . . . . . . . . . . . . . . 15 8. Normative References . . . . . . . . . . . . . . . . . . . . 14
4.7. ClientKeyExhange . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
4.8. CertificateVerify . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Finished . . . . . . . . . . . . . . . . . . . . . . . . 17
5. Comparison to Earlier Work . . . . . . . . . . . . . . . . . 17
6. Efficiency Considerations . . . . . . . . . . . . . . . . . . 18
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Kerberos lends itself well to infrastructure-supported mutual TLS protects many application protocols from many security problems.
authentication, and can even be used to crossover between realms. A To enable this, it habitually relies on public-key cryptography. But
downside of this infrastructure is that a crack of one key can lead in the foreseeable future, quantum computers are expected to destroy
to a cascade of reverse-engineered keys. Diffie-Hellman key these public-key underpinnings. This is not a current problem for
exchange, nowadays primarily in its Elliptic-Curve variation, can be authentication, but it does endanger encrypted data being passed
used to incorporate the desirable property of Forward Secrecy, but today, which may be captured and stored, ready for decryption as soon
its vulnerability to man-in-the-middle attacks must then be overcome as quantum computers hit the playing field.
by cryptographically binding it to an authentication mechanism.
This specification describes how Kerberos data structures can be used Most present-day applications of TLS are threatened by quantum
for TLS client authentication, by introducing a new certificate type computers; some may not be able to live up to legal requirements for
for use with TLS. The server can choose to provide a Certificate long-term encryption. There even is a risk of future power
with a traditional signing mechanism such as RSA for authentication, imbalances between those who have a quantum computer and those who
in which case this specification speaks of a KDH-enhanced exchange; have not.
even when presenting no server certificate at all, a client-side
Kerberos ticket can be used for mutual authentication in what will
then be called a KDH-only exchange. The KDH-enhanced variety uses
existing CipherSuite, and KDH-only defines new CipherSuites. Both
KDH-enhanced and KDH-only message flows will be referred to as TLS-
A variation of the KDH-only flow does incorporate a server-side The solution is to not rely solely on public-key cryptography, but
ticket; this can be used for user-to-user authentication, perhaps to instead mix in secret entropy that a future quantum computing entity
be used in peer-to-peer protocols that use TLS-KDH as their security cannot decipher. In this light, Kerberos offers an interesting
foundation. 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.
Both TLS-KDH variations form a cryptographic binding between Kerberos We therefore specify a quantum_relief extension that mixes secret
and Elliptic-Curve Diffie-Hellman (ECDH), leading to the combined entropy form another source into the TLS key computations, and we
advantages of infrastructure-supported mutual authentication and work out a concrete mechanism based on Kerberos. This concrete
Forward Secrecy. mechanism, which relies on Kerberos for relief from quantum computing
and on (Elliptic-Curve) Diffie-Hellman for Perfect Forward Secrecy
and to stop the sphere of influence of the KDC administrator, shall
be referred to as Kerberised Diffie-Hellman or KDH. A definition is
included for a KDH-Only Appllication Profile, to facilitate small and
simple implementations.
The normal flow of TLS-KDH messages is basically a standard In the the TLS 1.3 key schedule, the quantum_relief extension
interaction with a modified form of client Certificate and replaces the input from a PSK; the two extensions are not considered
CertificateVerify: useful when combined. In TLS 1.2, a similar result is achieved by
enhancing the pre-master secret independently of the negotiated
cipher suite.
Client Server 2. Quantum Relief from Pre-Shared Keys
ClientHello --------> The PSK mechanism in TLS 1.3 and 1.2 allows insertion of key material
ServerHello which is referenced by name alone. A naming system is defined, but
Server Certificate* its interpretation resides under local policy, which is enough for
ServerKeyExchange internal use cases, but it is insufficient for general use between
CertificateRequest any two parties.
<-------- ServerHelloDone
Client Certificate
Finished -------->
<-------- Finished
Application Data <-------> Application Data
* Indicates that Server Certificate may be empty; it is present in Cryptographically however, the entropy from the PSK mechanism in TLS
KDH-enhanced message flows, and usually empty in KDH-only message 1.3 is secret to external observers, and mixed with the DHE material
flows. using a series of HKDF-Extract and -Expand operations. 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 may not be
possible in all cases.
[] Indicates that ChangeCipherSpec is an independent TLS protocol This specification therefore defines a quantum_relief extension that
content type; it is not actually a TLS handshake message. replaces the locally useful PSK scheme with a generally usable
mechanism for insertion of secret entropy into the TLS 1.3 key
schedule in the position otherwise filled by the PSK. As a result,
TLS-KDH does not support 0-RTT data.
2. Extending Kerberos to support TLS Sufficient conditions to make entropy provide Quantum Relief are:
This section specifies individual extensions to Kerberos that make it o The amount of entropy must on its own suffice for the security
possible to use TLS. level of the TLS connection.
2.1. Checksum Types for use with TLS o The entropy must be secret, meaning invisible for outside
The IANA registry of Kerberos Parameters defines a number of Checksum o Only quantum-proof mechanisms should be used in the processing of
Types. This includes keyed and non-keyed checksums. We introduce the entropy.
checksum types to match the secure hash algorithms that are used in
There already are two values to represent SHA1. An implementation In terms of algorithms that are commonplace today, the third
that processes Checksum Types MAY send either and MUST accept both as requirement is generally believed to be met by secure hashes and
equivalent indications. symmetric encryption. The problem with these is sharing random
information secretely and at the same time controlling who has access
to these secrets. The infrastructure built by Kerberos provides a
good balance between these requirements, as a result of key
derivation to expand central secrets in an irreversible manner, so
that they may be distributed to various pairs of parties.
The following additional Checksum Types are introduced for use with 3. The Design of TLS-KDH
TLS [Section of [RFC5246]]:
o SHA224 The flow of TLS 1.3 works best when encryption is provided early, and
authentication is provided late. These things are often the same in
Kerberos, but KDH splits these responsibilities to be closer to TLS.
The TLS-KDH flow uses ClientHello and ServerHello for a Kerberos-
protected exchange of entropy, but it completely ignores 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
o SHA256 Server identity however, is observed in all Tickets, so any use of
the Ticket's contained key by the server suffices as proof of its
identity. This renders the server Certificate and CertificateVerify
messages redundant if the server accepts the KDH extension,
especially in TLS 1.3 because the Finished message follows
immediately. But redundancy can be a feature; it is certainly
legitimate to still authenticate the server with an explicit Kerberos
Ticket, X.509 certificate or other.
o SHA384 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.
o SHA512 The result offers almost-orthogonal Kerberos versions for (1)
additional secret entropy for encryption, (2) client authentication
through Kerberos Tickets and (3) server authentication through
Kerberos Tickets. All these aspects can independently provide
Quantum Relief. The only dependency between these is that the server
cannot initiate Kerberos, so (3) requires (1) or another Ticket
2.2. Authenticators as Signatures Besides the customary client-to-server flow there is also support for
a peer-to-peer flow in TLS-KDH. When this is used, the ClientHello
requests a remote peer identity and sends a TGT, possibly with
anonymous client name. Without documenting it here, the TLS server
is assumed to have some method of locating the remote client and
proxying the entire TLS connection to its endpoint. The remote peer
then returns a Ticket based on the TGT, obtained through the user-to-
user flow of Kerberos. This return Ticket will reverse the client
and server role relative to TLS, but for peer-to-peer connectivity
that does not matter. The remote peer, which is now the one
processing the TLS connection from the server side, will authenticate
itself through its use of this return Ticket and it can decide
whether authentication of the initiating client is desired. When the
client would authenticate through a Kerberos Ticket, this would
follow the client and server roles of Kerberos; as before, for peer-
to-peer traffic this should not be problematic, even if it imposes a
requirement on cross-realm connections that they must be
Kerberos has a symmetric analogue to a signature, in the form of an Whether a Ticket is supplied in the ClientHello or returned by a
Authenticator [Section 5.5.1 of [RFC4120]]. When used in TLS-KDH, remote peer in the ServerHello, it yields a key only to the two
the Authenticator MUST have a secure hash embedded in the cksum connecting parties. This key is used in standard Kerberos encryption
field. The checksum type used in the context of TLS MUST be taken to of the concatenated random data from ClientHello and ServerHello.
match one of the entries in IANA's TLS HashAlgorithm Registry. This means that both parties influence the entropy gathered and can
derive a sequence of bytes that is invisible to anyone else. The
output from the encryption operation is plugged into the key schedule
instead of the PSK input parameter. This input is designed for this
kind of loose entropy of arbitrary size.
The Authenticator is not sent in the plain, but encrypted with a 4. New Data Structures and Procedures
Kerberos session key as EncryptedData [Section 5.2.9 of [RFC4120]]
and this is how Kerberos derives authenticity: only the client and
the service can pack and unpack the EncryptedData and process the
A standard part of an Authenticator is a timestamp with microsecond The following data structures are used to define Quantum Relief for
accuracy. This is validated within a small window around the TLS 1.3 and 1.2, plus the more specific TLS-KDH form of Quantum
independently sycnchronised time of the TLS client and server. It is Relief.
customary to allow a time window of about 5 minutes around the server
To avoid replay attacks, Kerberos solutions sometimes need to 4.1. Extension quantum_relief
remember received Authenticators, or their time stamps, until the
time window has passed. This complicates servers, especially for
redundant deployments. As used in TLS-KDH, with entropy from both
end in the hello exchange and with session-specific keys agreed
through ephemeral ECDH, there is no need for such infrastructure to
avoid replay attacks. Notwithstanding that it is not as strong a
requirement as under other Kerberos applications, the cusec and ctime
fields are present in the Authenticator and MUST be filled with the
current time by the TLS-KDH client, and SHOULD be verified to fall
within a reasonable time frame on the TLS-KDH server.
In KDH-Enhanced mode an Authenticator MUST NOT contain a subkey The data passed during ClientHello and ServerHello are placed in an
field. In KDH-only mode, such a field MUST be supplied as input to extension called quantum_relief, of which KDH is currently the only
the premaster secret computation. form. A QuantumReliefForm tag is defined to set KDH aside from
possible future forms which, to be eligable, MUST assure the
sufficient conditions for Quantum Relief Section 2.
Other fields in the Authenticator than specified above SHOULD NOT be enum {
produced and MUST be ignored by the recipient. kdh(0),
} QuantumReliefMethod;
The representation on the wire matches the DigitallySigned structure The value kdh is always used for the method of Quantum Relief
[Section 4.7 of [RFC5246]] with the signature algorithm set to proposed herein, based on Kerberos.
kerberos, the hash set as desired for the TLS flow. The opaque
contents of the signature are filled with the literal bytes of the
Authenticator, which MUST NOT be an empty string.
2.3. Tickets in the TLS Certificate flow The ClientHello can additionally specify a name for a remote peer,
for which various application-independent forms may be anticipated;
this is captured in yet another tag PeerNameForm, of which only a
form for unencrypted Kerberos names is currently defined.
This specification defines a new certificate type [RFC7250] named enum {
KerberosTicket, to be negotiated for the client and, though only in none(0),
special circumstances, for the server. krb5princrealm(1),
} PeerNameForm;
The Kerberos Ticket is included in certificate messages following The value none is used for standard client-to-server TLS connections.
this syntax: The value krb5princrealm is used in a ClientHello to indicate a
Kerberos PrincipalName and Realm [Section 5.2.2 of [RFC4120]] for the
remote peer sought behind the TLS server.
struct { struct {
select(certificate_type){ PeerNameForm peernameform;
select (peernameform) {
// certificate type defined in this document. case none:
case KerberosTicket: opaque Ticket<0..2^24-1>; /* No peer name form */
// Additional certificate type based on case krb5princrealm:
// "TLS Certificate Types" subregistry /* PrincipalName and Realm, resp. */
}; struct {
} Certificate; opaque krb5princ<3..1023>;
In this syntax, Ticket holds the DER-encoded form of a Kerberos opaque krb5realm<3..1023>;
Ticket [Section 5.3 of [RFC4120]]. The special case where the Ticket } krb5PrincipalRealm;
field has length 0 marks an invalid ticket representation, and is }
treated by TLS-KDH as a refusal to send the requested ticket. QuantumReliefMethod qr_method;
select (qr_method) {
2.4. AuthorizationData for Backend Services case kdh:
/* Empty, ticket or TGT */
The TLS server may depend on additional Kerberos-protected services, opaque opt_ticket<0..65535>;
generally referred to as "backend services". As an example, a }
webmail service may need to access IMAP and SMTP backend services, } QuantumReliefExtension;
possibly under independent administrative control. This section
describes an OPTIONAL Kerberos mechanism in support of such backend
services. It is designed to even work when the client and server
reside in independently administered realms.
In addition to the main Ticket supplied in the client Certificate's
public key field, the TLS server MAY be sent additional Tickets for
access to backend services, and in some cases these additional
Tickets can define where these backend services are located and under
what client identity they are accessed. The client needs to provide
these additional Tickets in an AuthorizationData element whose ad-
type is AD-BACKEND-TICKETS (TBD) and whose ad-data holds a KRB-CRED
message [Section 5.8 of [RFC4120]] with an enc-part that uses NULL
encryption [Section 6.3.1 of [RFC1510]].
AuthorizationData elements with additional Tickets MAY be part of the
service Ticket and/or Authenticator; supporting TLS servers MUST
collect them from both these locations, such that they prefer the
former in cases of service name clashes. Just like a KDC could store
additional Tickets in the main Ticket, an explicitly configured
client could store them in the Authenticator. To remain secure,
clients MUST NOT be open to servers requesting arbitrary additional
Tickets in any way.
Additional Tickets MUST NOT be renewable, but the main Ticket MAY be;
when the main Ticket is renewed it SHOULD be resent with the backend
extension as they are setup at that time. Additional Tickets SHOULD
have neither the FORWARDABLE nor the PROXIABLE flag set.
Additional Tickets should normally be supplied every time the main
Ticket is supplied for TLS-KDH. As a result, both the main and
additional Tickets MAY be forgotten by the server whenever a TLS-KDH
session ends. However, when needed for longer-lasting or deferred
backend processing, the server MAY hold the Tickets longer.
It is possible for backend services to rely on backend services
themselves; this can be facilitated by a an AD-BACKEND-TICKETS
element contained in the additional Ticket for the respective backend
Ticket or, in more complex situations requiring more coordinated
configuration, in an Authenticator whose additional Tickets get
passed on selectively in Authenticators or other protocol elements
sent to the backend service.
The inclusion of additional Tickets in an Authenticator is not
further described in this specification. The inclusion of additional
Tickets in a main Ticket usually involves requesting the TLS-KDH
service Ticket directly from the client's KDC. TODO: To facilitate
this, the server desiring additional Tickets SHOULD set the
LocalRealmService flag Section 3.5; without this flag, the client MAY
choose not to supply additional Tickets. The use of this flag may
imply that the server needs to be flexible in the identity that the
client uses for its service.
3. Extending TLS to support Kerberos
This section describes changes to TLS in support of Kerberos.
3.1. Conceptual Data Model Extensions
The following conceptual data should be available while the TLS-KDH
message flows evolve:
o A flag that is initially set, indicating that the connection could
be a KDH-enhanced connection;
o A flag that is initially set, indicating that the connection could
be a KDH-only connection;
o A series of TicketRequestFlags that can be requested when the
client obtains a Ticket for this service.
3.2. Certificate Type KerberosTicket
This specification adds a new entry named kerberos_sign in IANA's TLS
ClientCertificateType Identifiers Registry, with the value TBD.
This specification also adds a new entry named KerberosTicket in
IANA's TLS Certificate Types" subregistry of the "Transport Layer
Security (TLS) Extensions" registry.
3.3. Signature Algorithms
This specification introduces a mechanism for signatures under
Kerberos Section 2.2. This mechanism is represented in two places.
In TLS, a new SignatureAlgorithm named kerberos is allocated with
value TBD in IANA's TLS Parameters Registry. This Kerberos
SignatureAlgorithm is usually combined with a HashAlgorithm that is
in common use with TLS, to form a SignatureAndHashAlgorithm. The
digitally-signed structure [Section 4.7 of [RFC5246]] uses this
structure, followed by a variable-sized opaque byte sequence, which
should hold the EncryptedData holding an Authenticator Section 2.2.
3.4. KDH-only CipherSuites
KDH-enhanced message flows can use existing ECDHE CipherSuites using
server certificates that may be signed with RSA or other common
algorithms. In addition, this specification introduces a number of
KDH-only CipherSuites with names that start with TLS_ECDHE_KDH_.
These new CipherSuites rely on Kerberos' mutual authentication plus
ECDHE but not on a server Certificate. They may be used starting
from TLS 1.2. They default to a higher verify_data_length than the
default 12.
The following Kerberos-only CipherSuites are entered into the IANA
TLS Cipher Suite Registry; the list below provides their names and
their desired verify_data_lengths between brackets:
Neither server nor client should accept lower values for
verify_data_length than given here. TODO: the list follows
http://www.keylength.com/en/4/ and the hash algorithm sizes -- is
this agreed?
The premaster secret for KDH-only CipherSuites is composed from an
ECDHE shared secret and a client-sent, connection-specific Kerberos
key. Use A to refer to the DER representation of the Authenticator
in the ClientVerify message. Perform the ECDH computation in the
normal manner [RFC4492] and let Z be the value produced by this
computation (with leading zero bytes kept as they are). The
premaster secret is the concatenation of an uint16 containing the
length of Z (in octets), Z itself, an uint16 containing the length of
A (in octets) and A itself.
The master secret is derived from the premaster secret using the
extended master secret computation [Section 4 of [RFC7627].
3.5. TicketRequestFlags Extension
Some clients may be able to offer more facilities in Tickets than This structure is used as extension_data following the quantum_relief
others, and some servers need more than others. To communicate this, extension_type, registered by IANA under number TBD:QREXTTYPE, to
a TLS Extension known as TicketRequestFlags is hereby defined. This occur only during ClientHello and ServerHello. IANA also created
extension is optional; when absent, all flags are considered to be registries for the QuantumReliefMethod and PeerNameForm in their
cleared. The client uses the Extension to specify the flags that it TBD:TLSExtensionsRegistry.
understands and may be able to fulfil. The server uses the Extension
to indicate the flags that it would like to be fulfilled.
The Extension's structure is an extensible list of flag values that 4.2. Ticket-based Encryption Procedure
indicate constraints on the ticket that the client should try to
supply. These should be seen as hints how the client should present
its identity, as the server can always decide to reject a client on
grounds that are or are not expressible in this form.
Flag values defined in this specification are: The TLS-KDH messages and cryptographic computations require the use
of the key concealed in a Ticket to produce a binary object that
cryptographically binds its input to the key. It is variably used as
a source of entropy and as proof, but it is always obtained through a
standard encryption procedure for Kerberos.
TicketFlags (flags number 0..31) are taken from Kerberos' Signature:
TicketFlags definitions [[RFC4120] and updates]; clients MUST o = Ticket-Encrypt (t, u, h)
NOT accept requested TicketFlags without scrutinising their
security impact; servers SHOULD NOT assume that their requested
TicketFlags will actually be provided. Only TicketFlags 0
through 31 are included in this definition; when Kerberos is
extended with more TicketFlags then they will be assigned a new
range of values as TicketRequestFlags.
VisibleClientRealm (flag number 32) requests that the client's realm Input:
name is revealed in the service ticket. With the flag not set, - Ticket t
the server MUST NOT reject the well-known anonymous realm name - KeyUsage u
WELLKNOWN:ANONYMOUS [Section 3 of [RFC6112]] in the client - Hash h
realm name.
UniqueClientIdentity (flag number 33) requests that the client Output:
presents a unique identity, even if it is a pseudonym that is - OctetString o
specific to this service. Some services can make good use of
identities that are also presented over other protocols, which
is why the choice to share such an identity SHOULD be made
during an interaction with the user, if possible. The user MAY
determine to use only a short-lived identity. When this flag
is not set, the server MUST NOT reject the client principal
[RFC6112]]. Regardless of this flag, it is RECOMMENDED for the
server to be open to as many forms of client principal name
[Section 6.2 of [RFC4120]] as possible.
LastingClientIdentity (flag number 34) requests that the client Steps:
presents an identity that it will use on recurring visits. 1. base-key = t.enc-part.key
Client software is advised to confer with their users on this, 2. specific-key = rfc3961.key-derivation (
and so this request should only be used for subscription base-key, u)
services that would be agreeable to their users. Without this 3. init-state = rfc3961.initial-cipher-state (
flag, the client is free to use a short-lived identity that is specific-key, DIRECTION_ENCRYPT)
unlikely to survive after the ticket's endtime or renew-till 4. (state,o) = rfc3961.encrypt (
time. specific-key, init-state)
The flags are chosen such that their default values may be set to 0 Not shown in the procedure, there is a need to decrypt the enc-part
as a safe default; safe in the sense that they do not lead to privacy of the Ticket before the key concealed in it can be extracted. This
problems, do not impair the peer and do not offer something that is where proof of identity comes into play; only the two parties
could block progress of TLS at a later point. Servers MUST NOT connected by the Ticket should be able to perform this decryption.
respond with TicketRequestFlags set that the client left cleared.
Senders MUST NOT include flags that they don't know and recipients
MUST NOT accept flags they cannot interpret.
Flag values are registered by IANA in a newly created "TLS-KDH Ticket The name prefix rfc3961 points to the generic descriptions for
Request Flag Registry", whose initial values are as defined above. Kerberos key-based procedures [RFC3961] that are implemented with
Future specifications of flag values may state that a flag is an various algorithms. Available algorithms are listed in the IANA
alternative to another flag, including to the ones specified above. Registry of Kerberos Parameters.
When flag A is an alternative to flag B then the fulfillment of the
requirements for A suffices to ignore flag B. It is possible for
flags to cyclically refer to each other as alternatives; since being-
an-alternative is not defined as a transitive property, this need not
distract from this definition. This is explicitly permitted to
enhance expressiveness of this principle.
The wire format representing TicketRequestFlags is a sequence of The Key Usage values are numbers, for which the following are defined
bytes, where the byte at index i (starting from 0) represents the by this specification. Their number ranges are deliberately chosen
flags numbered 8*i (in its least-significat bit) through 8*i+7 (in to not clash with those of Kerberos, but otherwise compliant to the
its most-significant bit). The last byte MUST NOT be 0, meaning that application range [Section 7.5.1 of [RFC4120]]. The Key Usage values
it is possible for the TicketRequestFlags to be a sequence of no are referenced by name elsewhere in this specification.
bytes if all flags are cleared.
3.6. TLS Connection Expiration 2008 = KEYUSAGE_TLS12KDH_PREMASTER_QR
TLS-KDH connections expire when their authenticating Kerberos tickets 4.3. Kerberos Ticket and TGT
expire. This is not a reason for termination of the TLS connection,
but instead it is a trigger for refreshing the ticket. Such a
refresh should be executed by the TLS-KDH client, where it may
trigger user interaction. Note that Kerberos' facility of ticket
renewal [Section 2.3 of [RFC4120]] may provide some relief from such
user interaction.
When the TLS-KDH connection expires, neither side will send any Where this text speaks of a TGT, short for Ticket Granting Ticket, it
further data records, and both sides will, upon receiving any data imposes the following requirements to the PrincipalName in the sname
records, trigger a TLS Alert. The other records are still accepted, field of a Ticket:
to permit a TLS handshake for re-issuance of session keys.
Implementations MAY choose to initiate and permit re-authentication
some time before the actual expiration. This can remedy clock skew
between the TLS-KDH client and server, which might otherwise lead to
undesired connection reset.
3.7. Interaction with Applications o The name-type is set to NT-SRV-INST or 2;
To be able to use Kerberos, application protocols that run over TLS o The name-string consists of two component strings;
must exchange some configuration information with the TLS stack.
This includes communication about Kerberos properties such as service
name and realm, offered/requested TicketRequestFlags, and a key for
use with the local identity.
When a SASL EXTERNAL mechanism is used to communicate an identity o The first name-string component string is the fixed string krbtgt.
between the application and the TLS stack, then a good alignment with
X.509 certificates is possible when both aim to derive or match a
Network Access Identifier [RFC7542] and/or a DNS name. In the case
of a Kerberos principal name, this would involve translation between
case-sensitive realm names to DNS names whose case is not reliably
reproduced [Section 4.1 of [RFC4343]]; this may be handled by
ignoring or lowering the case of the realm name while being aware of
the requirement that no two realm names may differ only in their case
[Section of [RFC4120]].
3.8. Kerberos-Only TLS Application Profile To be a TGT, all these requirements MUST be met by a Ticket; a Ticket
that meets some but not all these conditions is badly formed and the
recipient SHOULD respond to it by reporting error TODO:WHICH and
closing the connection.
TLS and Kerberos have long been independent infrastructures for 5. Changes to TLS Messages
secure connectivity; with the introduction of the KDH-only
CipherSuites in this specification, the worlds can merge elegantly.
The newly introduced CipherSuites are expected to integrate
relatively straightforwardly with any TLS stack.
Just like the TLS-KDH CipherSuites are optimal to implement in TLS There are a few modifications to TLS for the TLS-KDH message flow.
stacks, TLS-KDH should not force all Kerberos applications to process Unless specified otherwise, the modifications apply to TLS 1.3 and
the full potential of TLS, especially not public key cryptography and 1.2 alike.
the complexity of proper validation of X.509 certificates. Some
applications simply want to use Kerberos in a standardised protocol,
without any added CipherSuites. For such applications, we hereby
introduce a TLS application profile under which such applications can
stand on their own:
o Based on TLS 1.2 or newer; 5.1. ClientHello
o Setting a default verify_data_size dependent on the CipherSuite; 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 or peer-to-peer.
o Supporting the TLS-KDH CipherSuite To initiate client-to-server traffic, the peernameform MUST be set to
TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512; 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.
o Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA To initiate peer-to-peer traffic that could be proxied through the
CipherSuite that is mandatory in the default TLS application TLS server to end at a remote peer, the peernameform MUST NOT be set
profile [Section 9 of [RFC5246]]; to none, and the opt_ticket MUST be a TGT for the TLS client, suited
for the ticket granting service of the TLS server's realm; it is
permitted for the client to use an anonymous identity in this TGT and
the server MUST ignore the client identity in the opt_ticket. When
the peernameform is set to krb5princrealm, the krb5princ and
krb5realm fields MUST be set to the Kerberos PrincipalName and Realm
for the desired remote peer. Future extensions may introduce
alternative forms of remote peer identity and a TLS server SHOULD be
open to the general idea of identity.
o This application profile will be known as the "Kerberos-Only TLS When a ClientHello message contains a quantum_relief extension, it
Application Profile". MUST NOT include any references to a PSK. It MAY independently
negotiate client and server certificate types and cipher suites.
The Kerberos-only CipherSuites can be used with any TLS application 5.2. ServerHello
profile; that includes, but is not limited to, the one specified
above and the default application profile.
4. The Message Flow of TLS-KDH When the server accepts the quantum_relief extension, it replies with
its own quantum_relief extension and refrains from making any PSK
references. This specification defines a response to ClientHello
extensions with qr_method set to kdh, for which the ServerHello
extension MUST be set to kdh also.
This specification introduces the name TLS-KDH to certain message When the ClientHello extension had its peernameform set to none, the
flows within the TLS framework. There are two distinct variations, ServerHello extension responds to a client-to-server connection
called KDH-only and KDH-enhanced. This section defines constraints request. The TLS data will be terminated on the server and the
to the message flow for it to be a TLS-KDH message flow. This, response extension MUST set the opt_ticket field to a zero-length
together with the flags in the conceptual data model [Section 3.1], byte string.
guides the use of the extensions defined in this specification.
TLS endpoints that find that the other side of the TLS connection When the ClientHello extension had its peernameform set to another
only implements some of the TLS-KDH constraints MUST NOT continue the value than none, then the TLS server MUST use this to locate a remote
connection with the TLS-KDH extensions of this specification (unless peer, which may have registered through a mechanism not specified
future specifications assign a meaningful procedure for such herein, and proxy the TLS traffic to this remote peer. The TLS
situations). If the remote endpoint does not implement all server continues to proxy this traffic until it closes the
requirements for TLS-KDH but also enforces it, for instance by
sending required information that can only be interpreted under this
specification, then it MUST send a suitable TLS Alert and close the
connection. connection.
4.1. ClientHello When a remote peer, possibly after registering with a TLS server as a
recipient for client-to-client TLS connections, receives a
To support TLS-KDH, a client's ClientHello MUST mention the kerberos ClientHello with a quantum_relief extension with qr_method set to kdh
SignatureAlgorithm in at least one of the and a peernameform and peername that it recognises as its own and
supported_signature_algorithms, and it also MUST include with a TGT in the opt_ticket field, it should engage in a user-to-
KerberosTicket in a client_certificate_type extension [RFC7250]. The user ticket request with the ticket granting service for its realm.
client MAY include the TicketRequestFlags extension if it is It MUST reject the connection if this procedure fails. When a Ticket
interested on providing more than a generally available ticket to the is obtained, it constructs a ServerHello with a quantum_relief
service. extension, sets qr_method to kdh and peernameform to none, and
opt_ticket to the just-obtained Ticket. Furthermore, it continues to
Furthermore, the client MAY offer to process KerberosTicket in a act as though the client had contacted it directly, while being
server_certificate_type extension [RFC7250], and the client MAY forgiving to the proxied nature of the connection that carries the
include the TicketRequestFlags extension. TLS traffic. Specifically, there are no grounds for assuming
anything about the client identity, which may be undesirable in a
In addition, the ClientHello MAY include one or more KDH-only client-to-client connection.
CipherSuites in the list of cipher_suites, but if that is done the
protocol used MUST be TLS 1.2 or later, indicated on the record layer
with ProtocolVersion 3,3 or later. Without at least one of the KDH-
only CipherSuites, the connection cannot be KDH-only, but it may
still proceed as KDH-enhanced. With at least one of the KDH-only
CipherSuites, the client MAY offer to process KerberosTicket in a
server_certificate_type extension [RFC7250] through the ENC-TKT-IN-
SKEY [Section 2.9.2 of [RFC4120]] Kerberos extension.
The client MUST NOT send TicketRequestFlags that it does not
understand and it MUST NOT offer all the TicketFlags that are defined
for Kerberos, but instead SHOULD limit itself to what would be
acceptable from a security perspective.
4.2. ServerHello
To support TLS-KDH, a ServerHello message MUST mention the kerberos
SignatureAlgorithm in at least one of the
supported_signature_algorithms, and it MUST include the
KerberosTicket value in the client_certificate_type extension
[RFC7250]. Furthermore, the server MUST select a cipher_suite with
ephemeral ECDH key exchange; aside from generally available
CipherSuites, the server MAY select a KDH-only cipher_suite. When it
does not select a KDH-only CipherSuite, the connection cannot be a
KDH-only connection, but it may still proceed as KDH-enhanced.
When the server selects a KDH-enhanced CipherSuite, it MUST choose
another means of authenticating its identity than through Kerberos,
following the customary flow of TLS and only using Kerberos for
client authentication.
When the server selects a KDH-only CipherSuite and when the
ClientHello message includes the KerberosTicket in a
server_certificate_type extension [RFC7250], then the server MAY
choose to send back a server_certificate_type extension selecting
KerberosTicket, in which case it MUST send the corresponding Server
Certificate later in the process. This may be used to facilitate
user-to-user negotiation of TLS.
The server MAY include the TicketRequestFlags extension in the
ServerHello message if the client included it in the ClientHello
message. The server MUST ignore TicketRequestFlags from the client
that it does not understand; it MUST NOT send TicketRequestFlags that
it does not understand and it MUST NOT set TicketRequestFlags that
were not set in the ClientHello.
Note that none of the Anonymous CipherSuites can be made to work with
TLS-KDH, because then it is not permitted [Section 2.5 of [RFC4492]]
to send a CertificateRequest, client Certificate or CertificateVerify
message. Although the KDH-only CipherSuites do not use a server
Certificate this does not constitute Anonymous server authentication,
because Kerberos provides mutual authentication.
4.3. Server Certificate
For KDH-enhanced CipherSuites, the server Certificate message MUST be
sent, following the definitions of the server-selected cipher_suite.
Under KDH-only, when the server has not selected the KerberosTicket
as the server_certificate_type, then it MUST send an Certificate
message with a certificate_list of 0 bytes length.
Under KDH-only, when the server did select the KerberosTicket as the
server_certificate_type, then it MUST include the corresponding
ticket in the Server Certificate.
4.4. ServerKeyExchange
All TLS-KDH connections MUST use ephemeral ECDH. Under KDH-enhanced
CipherSuites, this implies the case ec_diffie_hellman [Section 5.4 of
[RFC4492]]. Under KDH-only CipherSuites, the same case is used, but
without signatures, formatted in the same way as for ECDH_anon
4.5. CertificateRequest
Under TLS-KDH, a CertificateRequest MUST be sent by the server, and
it MUST include at least one SignatureAndHashAlgorithm based on the
kerberos SignatureAlgorithm. Any SignatureAndHashAlogorithm with the
SignatureAlgorithm set to kerberos MUST use a HashAlgorithm for which
IANA's Kerberos Parameters registry holds a compatible Kerberos
Checksum Type. The CertificateRequest MUST also list the
kerberos_sign CertificateType. Having selected the KerberosTicket
value for the client_certificate_type, other CertificateTypes and
SignatureAndHashAlgorithms SHOULD NOT be sent. The list of
certificate_authorities is not used by TLS-KDH and MUST be empty.
4.6. Client Certificate
TLS-KDH clients MUST fill the ClientCertificate message with a
KerberosTicket. In doing so, it SHOULD take any negotiated
TicketRequestFlags into consideration; it is not required however to
implement all, because some flags may be forbidden by policy that was
concealed from the ClientHello-supplied TicketRequestFlags, or their
implementation may turn out to be unavailable while requesting the
Ticket. In such cases, the client MAY simply continue without
fulfilling the request flags, or it MAY choose to divert from a KDH-
enhanced message flow by authenticating with another kind of
Certificate, or not to present one at all.
When the server has not set the UniqueClientIdentity flag, then the
RECOMMENDED client Certificate under TLS-KDH would be based on an
anonymous Ticket [RFC6112]; however, when the server has set the
UniqueClientIdentity flag, then an anonymous Ticket that uses the
anonymous realm MUST NOT be sent. A Ticket that is not anonymous may
still be pseudonymous, including names based on NT-UID principal
names [Section 6.2 of [RFC4120]] when the server has sent the
UniqueClientIdentity flag; the LastingClientIdentity flag indicates
the server's perspecitve on longevity of any such pseudonyms, but the
client MAY choose to ignore that wish.
The impact of using an anonymous ticket is that the server cannot
establish the identity of the client, except perhaps that the same
service ticket may be used repeatedly during its short period of
validity. This means that the ability to trace the client is limited
for both server and client. Under customary X.509 authentication,
the interpretation of not sending the CertificateRequest is that the
server should not care for the client identity; anonymous tickets
provide a mechanism for achieving a similar pattern under TLS-KDH,
although it has some benefits of short-term session protection.
When the server has selected the KerberosTicket as the
server_certificate_type, then the client SHOULD pass it along with
its attempt to obtain a ticket for the server name, using the KDC
option ENC-TKT-IN-SKEY [Section 2.9.2 of [RFC4120]] and supplying an
additional ticket in the TGS request [Section 3.3.1 of [RFC4120]];
this Ticket is supplied completely by the KerberosTicket certificate-
type, and although it includes a server-side realm name, this MUST
NOT be trusted by the client before it has been confirmed by the
client's attempts to reach the server by its host name; this is
because a man-in-the-middle attack is still possible through a forged
service realm. Customary processing rules for finding a server's
realm MUST therefore be followed by the client.
The presence of the client's Ticket in the ClientCertificate message
enables the server to ascertain that the client has procured a Ticket
through the formal pathways of Kerberos, ending in the server-side
realm; the reason this can be assumed is that the ticket holds an
encrypted part that the server can decrypt and thereby validate with
its own key, as setup in its KDC for sharing in service tickets. In
other words, even an anonymous Ticket establishes that the server may
trust that the client was checked along the way to the service. As a
result, the ECDH key exchange is known to be protected from a man-in-
the-middle attack.
Briefly put, we can speak of mutual authentication in this
specification, even when the client supplies an anonymous ticket.
The only thing that is missing under an anonymous ticket is the
visibility of the client's validated identity.
4.7. ClientKeyExhange
Every TLS-KDH message flow MUST use ECDH, and since the keys MUST be
ephemeral, the explicit form of the ClientECDiffieHellmanPublic for
the case ec_diffie_hellman [Section 5.7 of [RFC4492]] MUST be used.
4.8. CertificateVerify
Under TLS-KDH, the CertificateVerify was preceded by a client's
Ticket, and the CertificateVerify MUST follow as a proof of posession
of the corresponding key material on the client. This means that the
CertificateVerify message MUST follow the descriptions of a Kerberos
Authenticator Section 2.2 for use with TLS.
The Authenticator MUST be set to the client's cusec and ctime values,
and the server SHOULD validate these to fall within a reasonable
margin around the current time.
The subkey field MUST NOT be included in KDH-enhanced message flows.
In KDH-only message flows, the Authenticator MUST introduce a new
client-generated key in the subkey field, and the client MUST supply
at least the amount of entropy in the subkey that is expected in the
symmetric key produced by TLS under the selected CipherSuite; the
server SHOULD validate this subkey size to provide, assuming optimal
compression, at least the amount of entropy that is desired for the
CipherSuite's symmetric key.
For KDH-Only, the subkey is needed to form the pre-master secret on
both ends, which in turn influences the master secret. Through the
Finished messages, the KDH-Only mode of operation performs mutual
validation between the client and server.
4.9. Finished
For KDH-enhanced flows, the server can be authenticated through its
Certificate, so that the usual Finished messages suffice, and TLS
versions preceding 1.2 may still suffice.
For KDH-only flows, the Finished message is the first place where the
server identity can be validated, prior to reporting successful
authentication to the application running atop TLS. As a result, the
KDH-only CipherSuites have been defined with an elongated Finished
message, for improved security. This is possible since TLS 1.2. The
desired minimum length is defined with the introduction of the KDH-
only CipherSuite.
5. Comparison to Earlier Work
An older specification [RFC2712] introduces Kerberos into TLS. That
specification is hereby deprecated because this new specification
improves on it work in a number of ways:
o The premaster secret is no longer sent to the server under
encryption with the KDC-provided session key; instead, Forward
Secrecy is supported through ECDHE;
o The authenticator following the Kerberos ticket is made
obligatory, as an intrinsic part of replay protection and the
mutual authentication between TLS client and TLS server to protect
all in-transit application data;
o There is no need to implement a replay cache, which means that
more efficient implementation is possible, certainly on highly
active and/or replicated TLS-KDH server systems;
o The mutual authentication of TLS client and TLS server is
established with Kerberos-only CipherSuites that define a stronger
Finished message size;
o The service name is not statically set to the literal "host", but
both the client and server TLS stacks assume an application
context to provide the service name to be used;
o The lack of forward secrecy in Kerberos is resolved by enforcing
ECDH with any use of TLS-KDH;
o The KDH-enhanced variation can be used with another mode of server 5.3. Server-sent VerifyRequest
o Support for modern TLS CipherSuites is added, and support for ones Since client identity is ignored by the server during ClientHello and
that are currently considered deprecated or insecure have been ServerHello and may indeed be toned down to an anonymous identity,
removed; any server-side requiring to know its client MAY send a
VerifyRequest. 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
(with much broader impact).
Specifically for the HTTP and HTTPS protocols, the Negotiate header The handshake is not encrypted in TLS 1.2, and for TLS 1.3 in peer-
[RFC4559] can provide Kerberos authentication, but its use is not to-peer mode the server-side identity is uncertain until the Finished
considered a strong security practice. Applications that currently messages. In the interest of the privacy of client identity, it may
rely on this mechanism can strengthen their security if they migrate be desirable to add server-side authentication even when it is not
to HTTP over TLS-KDH. Note that this provides an alternative for otherwise needed.
Kerberos, not to SPNEGO and not for general GSS-API protocols. This
restriction of TLS-KDH to Kerberos, rather than a more general GSS-
API protocol, is a result of the fixed number of message exchanges
available within TLS.
Many other protocols incorporate Kerberos through GSS-API, usually 5.4. Server-sent Certificate and CertificateVerify
via SASL. This is considered secure, but has an arguable
disadvantage of separating encryption and authentication layers, and
quite possibly also the identities involved in these layers.
Furthermore, encryption through SASL is not commonly used. In
situations where Kerberos is used for GSS-API over SASL, TLS-KDH
offers a comparable but more efficient and tighter-coupled mechanism
for encryption and mutual authentication, in a way that also lends
itself to non-SASL applications. Specifically useful in this respect
is that there is no longer a requirement to setup X.509 certificates
plus infrastructure and validation mechanisms, just to satisfy
encryption requirements with their own authentication infrastructure.
In applications that use SASL, the EXTERNAL mechanism [RFC4422] can
use the client identity in a Kerberos ticket, and make it available
to the application layer; SASL EXTERNAL is also commonly used when
TLS authenticates peers through X.509 certificates.
The use of additional Tickets for Backend Services Section 2.4 The Certificate and CertificateVerify messages are not always
replaces the paired practices "S4U2Self" and "S4U2Proxy", which were required, because (1) the quantum_relief extension captures the
not designed to crossover to hitherto unknown realms; they rely on server identity, and (2) proof thereof is deferred to Finished, which
the service realm to constrain the use of rights granted over the under TLS 1.3 is available to the client before it sends the client
client realm. Furthermore, said practices make use of hard-coded Certificate.
cryptographic algorithms, which makes it impossible to assure their
long-term security.
6. Efficiency Considerations Even in cases when it is not strictly required, a server MAY opt for
sending server Certificate and CertificateVerify, but in such cases
clients MUST NOT fail due to the messages being withheld.
The efficiency of the mechanism described here compares favourably The server_certificate_type extension may be used to negotiate any
with the more common approach of authentication through X.509 form for these messages, including the Kerberos Ticket certificate
certificates based on public-key algorithms. type defined herein. When not negotiated, the default form is X.509.
Note that a server cannot initiate a Kerberos exchange, so a Kerberos
form cannot be used when the server rejected the quantum_relief
extension or when the extension did not provide a Ticket or TGT such
as it does when the qr_method is kdh.
The Kerberos architecture is founded on symmetric cryptography, which 5.5. Client-sent Certificate and CertificateVerify
makes it more efficient than the asymmetric architectures around
X.509 public-key certificates. Furthermore, Kerberos' identity
statements are short-lived, which is generally accepted to evade the
need for withdrawal mechanisms based on chains of trust, CRLs
[RFC3280], OCSP [RFC6960], DANE [RFC6698] and perhaps other
mechanisms. As a result, the validity of a Kerberos ticket can be
checked with relatively modest computational effort.
The inclusion of ephemeral ECDH is a relatively expensive asymmetric Under TLS 1.3, the server can request client authentication at any
operation, but the same introduction is needed when Forward Secrecy time, provided that the client has sent the post_handshake_auth
is introduced alongside public-key authentication. extension. It is possible for servers to do this at any time, and
possibly multiple times; TLS 1.3 even defines how to handle
overlapping requests for client authentication.
The one thing that is costly about Kerberos is its reliance on a The client_certificate_type extension may be used to negotiate any
replay cache. Such caches store recent authentication attempts to form for these messages, including the Kerberos Ticket certificate
avoid that they are being replayed; an accurate clock helps to type define before. When not negotiated, the default form is X.509.
release entries, but some care for clock skew between TLS-KDH client Note that a client can produce a Kerberos Ticket even when no
and server must be resolved with these caches. Their volatile nature quantum_relief extension was negotiated during ClientHello and/or
makes them a particularly difficult problem in highly active and/or ServerHello, or even when another qr_method than kdh was agreed.
replicated and/or distributed Kerberos services.
A replay cache is not required for any of the TLS-KDH protocol flows, 5.6. Length of Finished
because this specification requires an ephemeral ECDH key exchange.
This is of particular use to redundant (and possibly distributed)
server farms, where sharing the time-critical information of the
replay cache is a performance bottle neck. Since this is a new
specification, there is no need to implement backward compatibility
with older mechanisms for which a replay cache might be needed.
7. Privacy Considerations 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 Finished message to be as long as the
hash being used to compute it and the server MUST accept this.
The information that is publicly shown in the TLS-KDH protocol flows 5.7. Selection of Cipher Suites
consists of:
o Supported protocol versions, TLS extensions and CipherSuites Under TLS 1.3, all cipher suites incorporate (Elliptic-Curve) Diffie-
Hellman. Under TLS 1.2 this is optional. For TLS-KDH under TLS 1.2
the client MUST offer cipher suites that include these forms of key
agreement and the server MUST NOT select a cipher suite without any
of these forms of key agreement.
o For other than Kerberos-only CipherSuites, the server's 5.8. Tickets and Connection Timing
o The server's principal name, host name and service name Tickets in Kerberos represent a key-based connection between two
peers. The key material in a Ticket is time-limited in the
understanding the 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 ERROR:WHICH
A Kerberos ticket transmits less information in plaintext than a To avoid this, it is possible to request a new client Certificate and
public-key X.509 client certificate; furthermore, DNS may have to CertificateVerify through a new VerifyRequest, best sent sometime
reveal the realm name(s) of server-trusted KDC(s) but neither the before expiry. The client then acquires a fresh or prolonged Ticket
TLS-KDH server nor any KDC publishes long-lasting key material for and once exchanged the connection may continue up to the timeout of
TLS or Kerberos, so parties looking for a cracking challenge are the new Ticket.
constrained to a brief period of attack on keys.
The TicketRequestFlags may provide information about Tickets present The timeout is updated by every new Ticket supplied in the opt_ticket
in the client, but that would take the risk of leaking information field of a quantum_relief extension with qr_method set to kdh, or by
prior to authentication of the server, and in plaintext. a Certificate of type Kerberos Ticket, provided that it is followed
by a valid CertificateVerify.
8. Security Considerations 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, but MAY
await the arrival a fresh 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 the client and server.
For KDH-enhanced message flows, the server can be authenticated Kerberos supports Tickets with future validity times, intended for
through its public-key X.509 Certificate. For KDH-onnly message such things as nightly batch jobs that require authentication. By
flows this is not possible, which is why a longer verify_data_size in default, a TLS stack MUST reject such Tickets until they start being
the Finished messages is required; the ability to generate these valid. It is however possible for applications to override this
messages properly proves that the other side has succeeded in behaviour and treat the connection especially after being informed of
decrypting the Kerberos-encrypted materials, and so, that it is the the future time at which it becomes valid.
intended remote party.
In Kerberos, all key material is supplied by the KDC. This is a 6. Cryptographic Updates
central point in each realm that is usually guarded well enough, but
it is nonetheless a critical point in any infrastructure founded on
Kerberos. When client and server are in different realms, but have
cross-signed directly or through a chain of KDC's, then all
intermediate KDC's are potential places where the session key could
be detected. The weakest KDC in the chain then defines the security
of the entire chain.
Kerberos requires accurate clocks in order to operate securely; The introduction of TLS-KDH leads to a few cryptographic changes to
without them, once-used and since-forgotten credentials could be the protocol and its implementation. Below, the three aspects
replayed by an attacker that has been able to recover an old service introduced by TLS-KDH are discussed independently. Separate
ticket's session key. This problem is worsened in cross-realm treatment for TLS 1.3 and 1.2 is only necessary for Quantum Relief
scenario's where clock synchronisation is hard to realise. This is for encryption.
however resolved in all TLS-KDH flows by using ephemeral Elliptic-
Curve Diffie-Hellman keys, thus forcing new master secrets on each
connection and removing the need for a replay buffer. Note however,
that ticket validity times must still be checked.
Basic Kerberos security hinges on the secrecy of the user's password; 6.1. Quantum Relief for Encryption in TLS 1.3
if this password is guessed, then all captured traffic can be
decoded, even in retrospect. This means that it is highly advisable
to combine Kerberos with Diffie-Hellman for Forward Secrecy. TLS-KDH
implies this desirable property in all its CipherSuites.
9. IANA Considerations Under client-to-server TLS-KDH, the opt_ticket in the quantum_relief
extension is used. Under peer-to-peer TLS-KDH, the TGT in the
opt_ticket supplies no shared key material to the client and server
(or remote 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.
IANA adds the following Kerberos Checksum Type Numbers to the The key is used to compute Ticket-Encrypt (opt_ticket, usage,
Kerberos Parameters registry, to match the hash algorithms available ClientHello.random | ServerHello.random) where | signifies
to TLS: 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 remote 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]]. Since none of the
PSK facilities are used under TLS-KDH, this seeding does not arrive
too late for the unfolding of the protocol.
+---------------+------------------+---------------+ Other qr_method values than kdh are likely to come up with other
| sumtype value | Checksum type | checksum size | 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
| TBD | sha224 (unkeyed) | 28 | the TLS 1.3 key schedule.
| TBD | sha256 (unkeyed) | 32 |
| TBD | sha384 (unkeyed) | 48 |
| TBD | sha512 (unkeyed) | 64 |
Through the IETF Kitten WG, the Kerberos community assigns the 6.2. Quantum Relief for Encryption in TLS 1.2
following value for the AuthorizationData type for backend tickets,
as defined in this specification:
+-------+--------------------+ TLS 1.2 does not offer any form of encryption during the handshake,
| Value | Name | so the kdh method for TLS 1.2 can only be used to strengthen the
+-------+--------------------+ Master Secret. When the quantum_relief extension is accepted by the
| TBD | AD-BACKEND-TICKETS | 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. This Ticket qrt is used to compute Ticket-Encrypt
(qrt, KEYUSAGE_TLS12KDH_PREMASTER_QR, ClientHello.random |
ServerHello.random), where | denotes concatenation. The output of
this procedure is a byte string. It is represented in a TLS type
IANA adds the following entries to the TLS Cipher Suite Registry opaque premaster_prefix<0..65535>
underneath the TLS Paramters registry, to enable KDH-only negotiation
and the Kerberos-Only profile that relies on it:
+-------+--------------------------------------------+---------+ and, in that form, prepended to the pre-master secret that the cipher
| Value | Description (verify_data_length) | DTLS-OK | suite defines. This prepended form is then used instead of the
+-------+--------------------------------------------+---------+ normal pre-master secret during the computation of the master key.
| TBD | TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32) | Y | Note that this is only done when client and server agreed to use the
| TBD | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48) | Y | quantum_relief extension with kdh as its method.
| TBD | TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA512 (64) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32) | Y |
| TBD | TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48) | Y |
IANA adds the following ClientCertificateType Identifier to the TLS TODO: Tom, dit is arbitrair. Hergebruik van code of structuren kan
Parameters registry, to be able to formule certificate requests under mogelijk soepeler, ik hoor het dan wel.
TLS-KDH as described in this document:
+-------+---------------+---------+ 6.3. Kerberos Ticket as Certificate and CertificateVerify
| Value | Description | DTLS-OK |
| TBD | kerberos_sign | Y |
IANA adds the following TLS SignatureAlgorithm to the TLS Parameters IANA has added Kerberos Ticket with value TBD:KRBTKT-CERTTP to the
registry, to permit the Kerberos-based signatures described in this TLS Certificate Types list in the TLS Extensions Registry. This can
document: be negotiated independently as client_certificate_type and
server_certificate_type, though the latter is impossible without a
client certificate, even if it is anonymous or just a TGT; in TLS-
KDH, this is available when the server accepts the quantum_relief
+-------+-------------+---------+ The contents of the Certificate message when the certificate type is
| Value | Description | DTLS-OK | negotiated as Kerberos Ticket is a Kerberos Ticket [RFC4120].
| TBD | kerberos | Y |
IANA adds the following TLS Certificate Type to the TLS Extensions The contents of the corresponding CertificateVerify message uses this
registry, to support negotiating it as a client_certificate_type and Ticket k5crt to compute Ticket-Encrypt (k5crt, KEYUSAGE_CLIENT_VFY,
possibly as a server_certificate_type: th) for a client CertificateVerify message or Ticket-Encrypt (k5crt,
KEYUSAGE_SERVER_VFY, th) for a server CertificateVerify message,
where th is the customary hash up to and including the preceding
Certificate message. For TLS 1.3, this customary hash uses the
transcript hash; for TLS 1.2, the hash algorithm must match the
Certificate signing algorithm, which in case of a Kerberos Ticket
means its MAC hashing algorithm.
+-------+----------------+---------+ 7. KDH-Only Application Profile
| Value | Description | DTLS-OK |
| TBD | KerberosTicket | Y |
IANA adds the following ExtensionType Value to the TLS Extensions The default use of TLS involves X.509 certificate processing with RSA
registry, to support the negotiation of TicketRequestFlags as keys, which may be a burden to some endpoints, especially when they
described in this specification: are very small or aim for simplicity. For this reason, this section
defines an alternative, KDH-Only Application Profile.
+-------+--------------------+ TLS-KDH-compliant applications MUST implement the
| Value | Extension Name | TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the
+-------+--------------------+ TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256
| TBD | TicketRequestFlags | [RFC8439] cipher suites.
IANA appends a new "TLS-KDH Ticket Request Flags" sub-register to the TLS-KDH-compliant applications MUST support the Kerberos Ticket
TLS Extensions register, to support the allocation of certificate type. The also MUST treat X.509 as the default
TicketRequestFlags by other specifications. New entries to this certificate type, but they MAY refuse any attempt to use it, either
table can be made under the named Assignment Policy [RFC5226]. The by negotiating it explicitly or failing to negotiate an alternative.
initial entries to this registry are:
+----------+-----------------------+--------------+-----------------+ TLS-KDH-compliant applications MUST support key exchange with
| Value(s) | Name | Reference | Assignment | secp256r1 (NIST P-256) and SHOULD support key exchange with X25519
| | | | Policy | [RFC7748].
| 0..31 | TicketFlags | TBD:THISSPEC | RFC Required |
| 32 | VisibleClientRealm | TBD:THISSPEC | RFC Required |
| 33 | UniqueClientIdentity | TBD:THISSPEC | RFC Required |
| 34 | LastingClientIdentity | TBD:THISSPEC | RFC Required |
| 35..63 | Unassigned | | RFC Required |
| 64..79 | Private Use | N/A | Private Use |
| 80..95 | Experimental | N/A | Experimental |
| | | | Use |
| 96.. | Reserved | | RFC Required |
10. References TLS-KDH-compliant applications MUST support the quantum_relief
extension, for which the qr_method value kdh MUST be supported, and
the peernametype value none MUST and krb5princrealm SHOULD be
10.1. Normative References 8. Normative References
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
Authentication Service (V5)", RFC 1510, Kerberos 5", RFC 3961, DOI 10.17487/RFC3961, February
DOI 10.17487/RFC1510, September 1993, 2005, <https://www.rfc-editor.org/info/rfc3961>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005, DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>. <https://www.rfc-editor.org/info/rfc4120>.
[RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case
Insensitivity Clarification", RFC 4343,
DOI 10.17487/RFC4343, January 2006,
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492,
DOI 10.17487/RFC4492, May 2006,
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
[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, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
10.2. Informative References
[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712,
DOI 10.17487/RFC2712, October 1999,
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
DOI 10.17487/RFC3280, April 2002,
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
DOI 10.17487/RFC7542, May 2015, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<http://www.rfc-editor.org/info/rfc7542>. <https://www.rfc-editor.org/info/rfc8446>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This specification could not have matured without the insights of This specification could not have matured without the insights of
various commenters. In order of appearance, we owe thanks to Simo various commenters. In order of appearance, we owe thanks to Simo
Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos Sorce, Ilari Liusvaara, Watson Ladd, Benjamin Kaduk, Nikos
Mavragiannopoulos. Special thanks go to Tom Vrancken for tracking Mavragiannopoulos.
the development of the specification, commenting on it and
implementing it in GnuTLS.
This work was conducted under a grant from the programme "[veilig] This work was conducted under a grant from the programme "[veilig]
door innovatie" from the government of the Netherlands. It has also door innovatie" from the government of the Netherlands. It has also
been liberally supported by the NLnet Foundation. been liberally supported by the NLnet Foundation.
Author's Address Authors' Addresses
Rick van Rein Rick van Rein
ARPA2.net ARPA2.net
Haarlebrink 5 Haarlebrink 5
Enschede, Overijssel 7544 WP Enschede, Overijssel 7544 WP
The Netherlands The Netherlands
Email: rick@openfortress.nl Email: rick@openfortress.nl
Tom Vrancken
Eindhoven, Noord-Brabant TODO
The Netherlands
Email: TODO
 End of changes. 117 change blocks. 
986 lines changed or deleted 503 lines changed or added

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