TLS-KDH: Kerberos + Diffie-Hellman in TLSARPA2.netHaarlebrink 5EnschedeOverijssel7544 WPThe Netherlandsrick@openfortress.nlThis specification defines a TLS message flow with Kerberos-based
(mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to
achieve Forward Secrecy for the session.Kerberos lends itself well to infrastructure-supported mutual
authentication, and can even be used to crossover between realms. A
downside of this infrastructure is that a crack of one key can lead to a cascade
of reverse-engineered keys. Diffie-Hellman key exchange, nowadays primarily
in its Elliptic-Curve variation, can be used to
incorporate the desirable property of Forward Secrecy, but its
vulnerability to man-in-the-middle attacks must then be overcome by cryptographically
binding it to an authentication mechanism.This specification describes how Kerberos data structures can be used for
TLS client authentication, by introducing a new certificate type for use with TLS.
The server can choose to provide a Certificate with a traditional
signing mechanism such as RSA for authentication,
in which case this specification speaks of a KDH-enhanced exchange;
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-KDH.A variation of the KDH-only flow does incorporate a server-side ticket;
this can be used for user-to-user authentication, perhaps to be used in
peer-to-peer protocols that use TLS-KDH as their security foundation.Both TLS-KDH variations form a cryptographic binding between Kerberos
and Elliptic-Curve Diffie-Hellman (ECDH), leading to the combined advantages of
infrastructure-supported mutual authentication and Forward Secrecy.The normal flow of TLS-KDH messages is basically a standard interaction
with a modified form of client Certificate and CertificateVerify:* Indicates that ServerCertificate is an optional message; it is present
for KDH-enhanced message flows, and absent for KDH-only message flows.[] Indicates that ChangeCipherSpec is an independent TLS
protocol content type; it is not actually a TLS
handshake message.Prior work exists for Kerberos authentication within TLS
.
This work has a few drawbacks that are addressed in
this new specification. Specifically, it is useful to combine Kerberos
mutual authentication with the Forward Secrecy of Diffie-Hellman.Specifically for the HTTP and HTTPS protocols, the Negotiate header
can provide Kerberos authentication, but its use is not considered a strong
security practice. Applications that currently rely on this mechanism can
strengthen their security if they
migrate to HTTP over TLS-KDH. Note that this provides an alternative
for 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 via SASL.
This is considered secure, but has an aguable 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
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.This section specifies individual extensions to Kerberos that make it possible
to use TLS.The IANA registry of Kerberos Parameters defines a number of Checksum
Types. This includes keyed and non-keyed checksums. We introduce
checksum types to match the secure hash algorithms that are used in TLS.There already are two values to represent SHA1. An implementation that
processes Checksum Types MAY send either and MUST accept both as equivalent
indications.The following additional Checksum Types are introduced for use with TLS
[Section 7.4.1.4.1 of ]:
SHA224SHA256SHA384SHA512Kerberos has a symmetric analogue to a signature, in the form of an Authenticator
[Section 5.5.1 of ]. When used in TLS-KDH,
the Authenticator MUST have a secure hash embedded
in the cksum field. The checksum type used in the context of TLS MUST be taken to
match one of the entries in IANA's TLS HashAlgorithm Registry.The Authenticator is not sent in the plain, but encrypted with a Kerberos
session key as EncryptedData [Section 5.2.9 of ]
and this is how Kerberos derives authenticity: only the client and the
service can unpack the EncryptedData and process the Authenticator.A standard part of an Authenticator is a timestamp with microsecond
accuracy. This is validated within a small window around the independently
sycnchronised time of the TLS client and server. It is customary to
allow a time window of about 5 minutes around the server time.To avoid replay attacks, Kerberos solutions sometimes need to 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.An Authenticator MAY contain a subkey field, used to provide keying material
to the other side. Under KDH-only, such a field MUST be supplied as input to the
premaster secret computation.Other fields in the Authenticator than specified above SHOULD NOT be produced
and MUST be ignored by the recipient.This specification defines a new certificate type
named KerberosTicket, to be negotiated for the client and, though only in special
circumstances, for the server.The Kerberos Ticket is included in certificate messages following this
syntax:In this syntax, Ticket holds the DER-encoded form of a Kerberos
Ticket [Section 5.3 of ].DISCUSSION: This is an alternative to S4U2Proxy, which relies on the server realm
to care for the provisioned rights. If TLS-KDH is to scale up to more loose
collaborations, without implied mutual trust, then it needs a new method for
backend service support. This is defined below.The TLS server may depend on additional Kerberos-protected services,
generally referred to as "backend services". As an example, a webmail service
may need to access IMAP and SMTP backend services, possibly under independent
administrative control. This section describes an OPTIONAL Kerberos
mechanism in support of such backend services.In addition to the main Ticket supplied in the client Certificate's
public key field, the TLS server would need Tickets to gain access to any
backend services, and in fact these Tickets can help to 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 ]
with an enc-part that uses NULL encryption [Section 6.3.1 of ].
The element may be carried in the authorization-data field of either the service
Ticket or an Authenticator.Additional Tickets MUST NOT be renewable, but the main Ticket
MAY be; when this
first 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 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 have backend services themselves;
this can be facilitated by a an AD-BACKEND-TICKETS element contained in the
respective backend service Ticket.The generation of AD-BACKEND-TICKETS at the client falls outside the
scope of this document, but it usually involves requesting the TLS-KDH service
Ticket from the client's KDC. To facilitate that, the server desiring additional
Tickets SHOULD set the LocalRealmService
flag ; 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.The client MUST NOT take hints from the server or any non-local KDC about
required backend Tickets; this might make the client's identity vulnerable.
This section describes changes to TLS in support of Kerberos.The following conceptual data should be available while the TLS-KDH message flows
evolve:
A flag that is initially set, indicating that the connection could be a KDH-enhanced connection;A flag that is initially set, indicating that the connection could be a KDH-only connection;A series of TicketRequestFlags that can be requested for a Ticket used in an X.509 client certificate.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.This specification introduces a mechanism for signatures under Kerberos
. 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
for a SignatureAndHashAlgorithm. The digitally-signed structure
[Section 4.7 of ] uses this structure, followed by
a variable-sized opaque byte sequence, which should hold the EncryptedData
holding an Authenticator .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:
TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32)TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48)TLS_ECDHE_KDH_WITH_AES_128_CCM (32)TLS_ECDHE_KDH_WITH_AES_256_CCM (48)TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32)TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48)
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 S to refer to the DER representation of the
EncryptionKey [Section 5.2.9 of ]
in the key contained in the Ticket in the client's Certificate.
Use E to refer to the DER representation of the
EncryptionKey
in the subkey field
of the Authentication in the ClientVerify message.
Perform the ECDH computation in the common manner 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 lenght of S (in octets), S itself,
the length of E (in octets) and E itself.
TODO: DER already has lengths, why prefix with uint16t (adds no entropy, but adds info relations)The master secret is derived from the premaster secret using the
extended master secret computation [Section 4 of .Some clients may be able to offer more facilities in Tickets than others,
and some servers need more than others. To communicate this, a TLS Extension
known as TicketRequestFlags is hereby defined. This extension is optional; when
absent, all flags are considered to be cleared. The client uses the Extension
to specify the flags that it 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 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:
are taken from Kerberos' TicketFlags definitions [ and updates]; clients MUST 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.
requests that the client's realm name is revealed in the service ticket. With the flag not set, the server MUST NOT reject the well-known anonymous realm name WELLKNOWN:ANONYMOUS [Section 3 of ] in the client realm name.
requests that the client presents a unique identity, even if it is a pseudonym that is 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 name WELLKNOWN/ANONYMOUS of type KRB_NT_WELLKNOWN [Section 3 of ]. 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 ] as possible.
requests that the client presents an identity that it will use on recurring visits. Client software is advised to confer with their users on this, and so this request should only be used for subscription services that would be agreeable to their users. Without this flag, the client is free to use a short-lived identity that is unlikely to survive after the ticket's endtime or renew-till time.The flags are chosen such that their default values may be set to 0 as a safe default; safe in the sense that they do not lead to privacy problems, do not impair the peer and do not offer something that could block progress of TLS at a later point. Servers MUST NOT 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 Request Flag Registry", whose initial values are as defined above. Future specifications of flag values may state that a flag is an alternative to another flag, including to the ones specified above. 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 bytes, where the byte at index i (starting from 0) represents the flags numbered 8*i (in its least-significat bit) through 8*i+7 (in its most-significant bit). The last byte MUST NOT be 0, meaning that it is possible for the TicketRequestFlags to be a sequence of no bytes if all flags are cleared.TLS-KDH connections expire when their authenticating Kerberos tickets
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 ] may
provide some relief from such user interaction.When the TLS-KDH connection expires, neither side will send any further data
records, and both sides will, upon receiving any data records, trigger a TLS Alert.
The other records are still accepted, 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.To be able to use Kerberos, application protocols that run over TLS 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 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
and/or a
domain 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 ];
this may be handled by ignoring or lowering the case of the realm name while
upholding the requirement that no two realm names may differ only in their case
[Section 7.2.3.1 of ].TLS and Kerberos have long been independent infrastructures for 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 stacks,
TLS-KDH should not force all Kerberos applications to process the full potential
of TLS, especially not public key cryptography and 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:
Based on TLS 1.2 or newer;Setting a default verify_data_size dependent on the CipherSuite;Supporting the TLS-KDH CipherSuite TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384;Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA CipherSuite
that is mandatory in the default TLS application profile
[Section 9 of ];This application profile will be known as the "Kerberos-Only TLS Application Profile".The Kerberos-only CipherSuites can be used with any TLS application profile; that
includes, but is not limited to, the one specified above and the
default application profile.This specification introduces the name TLS-KDH to certain message flows within
the TLS framework. There are two distinct variations, called KDH-only and KDH-enhanced.
This section defines constraints to the message flow for it to be a
TLS-KDH message flow. This, together with the flags in the conceptual data model
[], guides the use of the extensions defined in this
specification.TLS endpoints that find that the other side of the TLS connection only
implements some of the TLS-KDH constraints MUST NOT continue the connection
with the TLS-KDH extensions of this specification (unless future specifications
assign a meaningful procedure for such situations). If the remote endpoint
does not implement all 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.To support TLS-KDH, a client's ClientHello MUST mention the kerberos
SignatureAlgorithm in at least one of the supported_signature_algorithms,
and it also MUST include KerberosTicket in a client_certificate_type extension
. The client MAY include the TicketRequestFlags extension
if it is interested on providing more than a generally available ticket to the
service.Furthermore, the client MAY offer to process
KerberosTicket in a server_certificate_type extension ,
and the client MAY include the TicketRequestFlags extension.In addition, the ClientHello MAY include one or more KDH-only 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 through the
ENC-TKT-IN-SKEY [Section 2.9.2 of ] 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.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 .
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 , 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 ] 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.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 NOT send a Certificate message.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.All TLS-KDH connections MUST use ephemeral ECDH. Under
KDH-enhanced CipherSuites, this implies the case ec_diffie_hellman
[Section 5.4 of ]. Under KDH-only CipherSuites,
the same case is used, but without signatures, formatted in the same way as for
ECDH_anon CipherSuites.Under TLS-KDH, a CertificateRequest MUST be sent by the server, and it MUST
include at least one SignatureAndHashAlgorithm based on the kerberos
SignatureAlgorithm, and it MUST 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.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 ; 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 ] 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 ] and supplying an additional ticket in
the TGS request [Section 3.3.1 of ]; 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.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 ] MUST
be used.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
for use with TLS.In KDH-only message flows, the Authenticator MUST introduce a new client-generated
key in the subkey field, to be used in the formation of the premaster secret.
The subkey field SHOULD NOT be included in KDH-enhanced message flows.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.An older specification introduces Kerberos into TLS.
That specification is hereby deprecated because this new specification improves
on it work in a number of ways:
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;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;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;The mutual authentication of TLS client and TLS server is established with
Kerberos-only CipherSuites that define a stronger Finished message size;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;The KDH-enhanced variation can be used with another mode of server
authentication.Support for modern TLS CipherSuites is added,
and support for ones that are currently considered deprecated or insecure
have been removed;The efficiency of the mechanism described here compares favourably with
the more common approach of authentication through X.509 certificates
based on public-key algorithms.The Kerberos architecture is founded on symmetric
cryptography, which 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 , OCSP ,
DANE
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 operation, but the same introduction is needed when
Forward Secrecy is introduced alongside public-key authentication.The one thing that is costly about Kerberos is its reliance on a replay
cache. Such caches store recent authentication attempts to avoid that
they are being replayed; an accurate clock helps to release entries, but
some care for clock skew between TLS-KDH client and server must be resolved
with these caches. Their volatile nature makes them a particularly difficult
problem in highly active and/or replicated and/or distributed Kerberos
services.A replay cache is not required for any of the TLS-KDH protocol flows,
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.The information that is publicly shown in the TLS-KDH protocol flows consists of:
Supported protocol versions, TLS extensions and CipherSuitesFor other than Kerberos-only CipherSuites, the server's CertificateThe server's principal name, host name and service nameA Kerberos ticket transmits less information in plaintext than a public-key X.509 client
certificate; furthermore, DNS may have to reveal the realm name(s) of server-trusted
KDC(s) but neither the TLS-KDH server nor any KDC publishes long-lasting
key material for TLS or Kerberos, so parties looking for a cracking challenge are
constrained to a brief period of attack on keys.The TicketRequestFlags may provide information about Tickets present in
the client, but that would take the risk of leaking information prior to
authentication of the server, and in plaintext.For KDH-enhanced message flows, the server can be authenticated through
its public-key X.509 Certificate. For KDH-onnly message flows this is not possible,
which is why a longer verify_data_size in the Finished messages is required;
the ability to generate these messages properly proves that the other side
has succeeded in decrypting the Kerberos-encrypted materials, and so, that it is
the intended remote party.In Kerberos, all key material is supplied by the KDC. This is a 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; without
them, once-used and since-forgotten credentials could be replayed by an
attacker that has been able to recover an old service ticket’s session
key. This problem is worsened in cross-realm scenario’s where clock
synchronisation is hard to realise. This is 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;
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.IANA adds the following Kerberos Checksum Type Numbers to the
Kerberos Parameters registry, to match the hash algorithms
available to TLS:sumtype valueChecksum typechecksum sizeTBDsha224 (unkeyed)28TBDsha256 (unkeyed)32TBDsha384 (unkeyed)48TBDsha512 (unkeyed)64Through the IETF Kitten WG, the Kerberos community assigns the following value
for the AuthorizationData type for backend tickets, as defined in this
specification:ValueNameTBDAD-BACKEND-TICKETSIANA adds the following entries to the TLS Cipher Suite Registry underneath
the TLS Paramters registry, to enable KDH-only negotiation and the Kerberos-Only
profile that relies on it:ValueDescription (verify_data_length)DTLS-OKTBDTLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32)YTBDTLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48)YTBDTLS_ECDHE_KDH_WITH_AES_128_CCM (32)YTBDTLS_ECDHE_KDH_WITH_AES_256_CCM (48)YTBDTLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32)YTBDTLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48)YIANA adds the following ClientCertificateType Identifier to the
TLS Parameters registry, to be able to formule certificate requests
under TLS-KDH as described in this document:ValueDescriptionDTLS-OKTBDkerberos_signYIANA adds the following TLS SignatureAlgorithm to the
TLS Parameters registry, to permit the Kerberos-based signatures described in
this document:ValueDescriptionDTLS-OKTBDkerberosYIANA adds the following TLS Certificate Type to the
TLS Extensions registry, to support negotiating it as a client_certificate_type
and possibly as a server_certificate_type:ValueDescriptionDTLS-OKTBDKerberosTicketYIANA adds the following ExtensionType Value to the
TLS Extensions registry, to support the negotiation of TicketRequestFlags as
described in this specification:ValueExtension NameTBDTicketRequestFlagsIANA appends a new "TLS-KDH Ticket Request Flags" sub-register to the
TLS Extensions register, to support the allocation of TicketRequestFlags by
other specifications.
New entries to this table can be made under the named Assignment Policy
.
The initial entries to this registry are:Value(s)NameReferenceAssignment Policy0..31TicketFlagsTBD:THISSPECRFC Required32VisibleClientRealmTBD:THISSPECRFC Required33UniqueClientIdentityTBD:THISSPECRFC Required34LastingClientIdentityTBD:THISSPECRFC Required35..63UnassignedRFC Required64..79Private UseN/APrivate Use80..95ExperimentalN/AExperimental Use96..ReservedRFC RequiredTODO