TLS-KDH: Kerberos + Diffie-Hellman in TLS
draft-vanrein-tls-kdh-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Rick van Rein | ||
| Last updated | 2016-03-11 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vanrein-tls-kdh-02
Network Working Group R. Van Rein
Internet-Draft ARPA2.net
Intended status: Standards Track March 11, 2016
Expires: September 12, 2016
TLS-KDH: Kerberos + Diffie-Hellman in TLS
draft-vanrein-tls-kdh-02
Abstract
This specification defines a TLS message flow with Kerberos-based
(mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to
achieve Forward Secrecy for the session.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Van Rein Expires September 12, 2016 [Page 1]
Internet-Draft TLS-KDH March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Extending Kerberos to support TLS . . . . . . . . . . . . . . 4
3.1. Checksum Types for use with TLS . . . . . . . . . . . . . 4
3.2. Authenticators as Signatures . . . . . . . . . . . . . . 5
3.3. Tickets in X.509 Certificates . . . . . . . . . . . . . . 5
3.4. AuthorizationData for Backend Services . . . . . . . . . 7
4. Extending TLS to support Kerberos . . . . . . . . . . . . . . 8
4.1. Conceptual Data Model Extensions . . . . . . . . . . . . 8
4.2. Client Certificate Type . . . . . . . . . . . . . . . . . 8
4.3. Signature Algorithms . . . . . . . . . . . . . . . . . . 8
4.4. KDH-only CipherSuites . . . . . . . . . . . . . . . . . . 9
4.5. TicketRequestFlags Extension . . . . . . . . . . . . . . 10
4.6. TLS Connection Expiration . . . . . . . . . . . . . . . . 12
4.7. Interaction with Applications . . . . . . . . . . . . . . 12
4.8. Kerberos-Only TLS Application Profile . . . . . . . . . . 13
5. The Message Flow of TLS-KDH . . . . . . . . . . . . . . . . . 13
5.1. ClientHello . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. ServerHello . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Server Certificate . . . . . . . . . . . . . . . . . . . 15
5.4. ServerKeyExchange . . . . . . . . . . . . . . . . . . . . 15
5.5. CertificateRequest . . . . . . . . . . . . . . . . . . . 15
5.6. Client Certificate . . . . . . . . . . . . . . . . . . . 15
5.7. ClientKeyExhange . . . . . . . . . . . . . . . . . . . . 17
5.8. CertificateVerify . . . . . . . . . . . . . . . . . . . . 17
5.9. Finished . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Comparison to Earlier Work . . . . . . . . . . . . . . . . . 17
7. Efficiency Considerations . . . . . . . . . . . . . . . . . . 18
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
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.
Van Rein Expires September 12, 2016 [Page 2]
Internet-Draft TLS-KDH March 2016
This specification describes how Kerberos data structures can be used
for TLS client authentication, by embedding Kerberos data in X.509
client certificates and signatures. The server can still present a
Certificate with a traditional signing mechanism such as RSA for
authentication, in which case this specification speaks of a KDH-
enhanced exchange; in absense of a server Certificate the Kerberos-
based X.509 format 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.
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:
Client Server
ClientHello -------->
ServerHello
ServerCertificate*
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* 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.
Van Rein Expires September 12, 2016 [Page 3]
Internet-Draft TLS-KDH March 2016
2. Related Work
Prior work exists for Kerberos authentication within TLS [RFC2712].
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
[RFC4559] 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 [RFC4422] can use
the client identity in a Kerberos ticket, and make it available to
the application layer; SASL EXTERNAL is also used when TLS
authenticates peers through X.509 certificates.
3. Extending Kerberos to support TLS
This section specifies individual extensions to Kerberos that make it
possible to use TLS.
3.1. Checksum Types for use with 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.
Van Rein Expires September 12, 2016 [Page 4]
Internet-Draft TLS-KDH March 2016
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 [RFC5246]]:
o SHA224
o SHA256
o SHA384
o SHA512
3.2. Authenticators as Signatures
Kerberos has a symmetric analogon to a signature, namely an
Authenticator [Section 5.5.1 of [RFC4120]]. 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 [RFC4120]]
and this is how it provides 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 need to remember received
Authenticators, or their time stamps, until the time window has
passed. This can complicate servers, especially for redundant
deployments. When combined with ephemeral ECDH, there is no need for
such infrastructure to avoid replay attacks.
Other fields in the Authenticator than specified above MUST be
ignored by the recipient.
3.3. Tickets in X.509 Certificates
This specification leaves the certification possibilities for servers
in tact, even if it extends the client certification side. This is
why it is not desirable to define a new certificate type [RFC5801]
Van Rein Expires September 12, 2016 [Page 5]
Internet-Draft TLS-KDH March 2016
for Kerberos, as that would impact the server certificate. Instead,
we define a method to encapsulate Kerberos credentials in the general
X.509 certificate format on the client side.
Kerberos is based on symmetric keys, but its infrastructure is
similar to a public-key cryptosystem. The main difference is that
its cryptographic claims can only be verified by a targeted service,
but within the scope of TLS this does not present any problems.
Embedding a Kerberos Ticket into an X.509 certificate is akin to
tunneling, where a message is packed into a message with a similar
purpose.
The X.509 client certificate is constructed from Kerberos by building
a TBSCertificate [Section 4.1 of [RFC5280]] as follows:
o The certificate is self-signed. Its issuer and subject are set to
the distinguishedName CN=Kerberos.
o The certificate MUST NOT claim validity before its contained
Ticket is valid, and MUST NOT claim validity after the Ticket
expires. The certificate MAY be short lived, lasting for example
from 2 minutes before the client's current time to 3 minutes after
the current time.
o The signature algorithm is set to an OID that signifies an
Authenticator as specified in Section 3.2 and based on a TLS-
accepted hash algorithm. The Authenticator MUST NOT contain a
subkey field.
o The subjectPublicKeyInfo is set to an algorithm OID that signifies
a Kerberos Ticket; the subjectPublicKey is filled with a Kerberos
Ticket [Section 5.3 of [RFC4120]] that the client wants to use to
access a service.
The Certificate built from the TBSCertificate adds the following
fields:
o The signatureAlgorithm contains the same value as the signature
field in the TBSCertificate.
o The signatureValue field is filled with the EncryptedData
Section 3.2 holding an Authenticator whose cksum is computed over
the TBSCertficate using the secure hash algorithm specified in the
signatureAlgorithm.
The OIDs referred to above are defined below Section 4.3.
Van Rein Expires September 12, 2016 [Page 6]
Internet-Draft TLS-KDH March 2016
3.4. AuthorizationData for Backend Services
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 [RFC4120]] with an enc-part that uses NULL encryption
[Section 6.3.1 of [RFC1510]]. 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 Section 4.5; without this flag, the client MAY choose not to
supply additional Tickets. The use of this flag may imply that the
Van Rein Expires September 12, 2016 [Page 7]
Internet-Draft TLS-KDH March 2016
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.
4. Extending TLS to support Kerberos
This section describes changes to TLS in support of Kerberos.
4.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 for a Ticket
used in an X.509 client certificate.
4.2. Client Certificate Type
This specification adds a new entry named kerberos_sign in IANA's TLS
ClientCertificateType Identifiers Registry, with the value TBD.
4.3. Signature Algorithms
This specification introduces a mechanism for signatures under
Kerberos Section 3.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 for 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 3.2.
In X.509 certificates, an AlgorithmIdentifier is used to represent
the combination of a signature and hash algorithm. This consists of
an OID and optional parameters. For the Kerberos signature
algorithm, the parameters are absent, and the OID is (TBD -- for now,
1.3.6.1.4.1.44469.666.509.88.1.1.2) concatenated with the OID of a
Van Rein Expires September 12, 2016 [Page 8]
Internet-Draft TLS-KDH March 2016
secure hash algorithm from IANA's Hash Function Textual Names
registry. For example, the SHA-1 hash with OID 1.3.14.3.2.26 would
combine to form (TBD -- now it is
1.3.6.1.4.1.44469.666.509.88.1.1.2.1.3.14.3.2.26).
4.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:
o TLS_ECDHE_KDH_WITH_AES_128_GCM_SHA256 (32)
o TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384 (48)
o TLS_ECDHE_KDH_WITH_AES_128_CCM (32)
o TLS_ECDHE_KDH_WITH_AES_256_CCM (48)
o TLS_ECDHE_KDH_WITH_AES_128_CCM_8 (32)
o TLS_ECDHE_KDH_WITH_AES_256_CCM_8 (48)
o TLS_ECDHE_KDH_WITH_ARIA_128_GCM_SHA256 (32) (TODO:WHY IS ARIA IN
TLS 1.3?)
o TLS_ECDHE_KDH_WITH_ARIA_256_GCM_SHA384 (48) (TODOWHY IS ARIA IN
TLS 1.3REALLY?)
o TLS_ECDHE_KDH_WITH_CAMELLIA_128_GCM_SHA256 (32) (TODO:WHY IS
CAMELLIA IN TLS 1.3?)
o TLS_ECDHE_KDH_WITH_CAMELLIA_256_GCM_SHA384 (48) (TODO:WHY IS
CAMELLIA IN TLS 1.3?)
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?
Van Rein Expires September 12, 2016 [Page 9]
Internet-Draft TLS-KDH March 2016
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 [RFC4120]] 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, which MUST be present. Perform the ECDH
computation in the common 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 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 [RFC7627].
4.5. TicketRequestFlags Extension
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 for TLS in general, but it is required for TLS-
KDH. 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 requires to be fulfilled.
The Extension's structure is an extensible list of flag values that
indicate constraints on the ticket that the client should 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:
TicketFlags (flags number 0..31) are taken from Kerberos'
TicketFlags definitions [[RFC4120] 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.
CrossoverRealm (flag number 32) indicates that the client SHOULD be
inquisitive about redirections to other realm than its own;
this MAY be defined in locally trusted domain-to-realm
Van Rein Expires September 12, 2016 [Page 10]
Internet-Draft TLS-KDH March 2016
mappings; and the client SHOULD request a service ticket under
canonicalization [RFC6806] and be open to server referrals.
When this flag is not set, the server MUST accept the client
realm on the tickets received, and its setup must make the
effort of connecting to the realm of the clients that it wants
to support.
VisibleClientRealm (flag number 33) 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 [RFC6112]] in the client
realm name.
UniqueClientIdentity (flag number 34) 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
[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.
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 to its across its next Authentication
Service request.
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
Van Rein Expires September 12, 2016 [Page 11]
Internet-Draft TLS-KDH March 2016
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.
4.6. TLS Connection Expiration
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 [RFC4120]] 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.
4.7. Interaction with Applications
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, requested/accepted 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 [RFC7542] 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 [RFC4343]]; this may be handled
by ignoring or lowering the case of the realm name while upholding
Van Rein Expires September 12, 2016 [Page 12]
Internet-Draft TLS-KDH March 2016
the requirement that no two realm names may differ only in their case
[Section 7.2.3.1 of [RFC4120]].
4.8. Kerberos-Only TLS Application Profile
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:
o Based on TLS 1.2 or newer;
o Setting a default verify_data_size dependent on the CipherSuite;
o Supporting the TLS-KDH CipherSuite
TLS_ECDHE_KDH_WITH_AES_256_GCM_SHA384;
o Not necessarily supporting the TLS_RSA_WITH_AES_128_CBC_SHA
CipherSuite that is mandatory in the default TLS application
profile [Section 9 of [RFC5246]];
o 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.
5. The Message Flow of TLS-KDH
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 [Section 4.1],
guides the use of the extensions defined in this specification.
Van Rein Expires September 12, 2016 [Page 13]
Internet-Draft TLS-KDH March 2016
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.
5.1. ClientHello
To support TLS-KDH, a client's ClientHello message MUST include the
TicketRequestFlags extension, and it MUST mention the kerberos
SignatureAlgorithm in at least one of the
supported_signature_algorithms.
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.
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.
5.2. ServerHello
To support TLS-KDH, a ServerHello message MUST include the
TicketRequestFlags extension, and it MUST mention the kerberos
SignatureAlgorithm in at least one of the
supported_signature_algorithms. To continue the message flow as TLS-
KDH, 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.
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]]
Van Rein Expires September 12, 2016 [Page 14]
Internet-Draft TLS-KDH March 2016
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.
5.3. Server Certificate
When a KDH-only CipherSuite was selected in the ServerHello, then the
server MUST NOT send a Certificate message. For KDH-enhanced
CipherSuites, the server Certificate message MUST be sent, following
the definitions of the server-selected cipher_suite.
5.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
CipherSuites.
5.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, and it MUST list the kerberos_sign
CertificateType. For KDH-only CipherSuites, no other
CertificateTypes and SignatureAndHashAlgorithms are permitted. The
list of certificate_authorities is not used by TLS-KDH and MUST be
empty for KDH-only CipherSuites.
When sending a CertificateRequest under TLS-KDH, the TLS server MUST
be prepared to accept the X.509 certificate form for Kerberos
[Section 3.3] using any of the corresponding signature algorithm OIDs
[Section 4.3].
5.6. Client Certificate
A client MAY choose any of the certificate and signature types to
fulfil the CertificateRequest. In order to continue the TLS-KDH
message flow, it MUST select the kerberos_sign CertificateType and a
SignatureAndHashAlgorithm with the kerberos SignatureAlgorithm.
Under TLS-KDH the client MUST supply a Certificate based on these
algorithms.
When continuing with the TLS-KDH flow, the client SHOULD take the
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 that
Van Rein Expires September 12, 2016 [Page 15]
Internet-Draft TLS-KDH March 2016
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.
Under the present specification, the kerberos_sign CertificateType
and the kerberos SignatureAlgorithm SHOULD NOT be used independently,
but always in combination [Section 3.3]. If any of the messages
preceding the client's Certificate deviated from the specifications
for TLS-KDH, then these choices MUST NOT be made. Only when these
two choices are made do we continue to speak of a TLS-KDH message
flow.
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.
The presence of a Ticket enables the server to conclude 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 uses an anonymous ticket. The
Van Rein Expires September 12, 2016 [Page 16]
Internet-Draft TLS-KDH March 2016
only thing that is missing under an anonymous ticket is the
visibility of the client's validated identity.
5.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.
5.8. CertificateVerify
If CertificateVerify was preceded by a client Certificate with the
kerberos SignatureAlgorithm, then the CertificateVerify MUST follow
up accordingly. This means that the CertificateVerify message MUST
follow the descriptions of a Kerberos Authenticator Section 3.2 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.
5.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.
6. 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
Van Rein Expires September 12, 2016 [Page 17]
Internet-Draft TLS-KDH March 2016
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 KDH-enhanced variation can be used with another mode of server
authentication.
o Support for modern TLS CipherSuites is added, and support for ones
that are currently considered deprecated or insecure have been
removed;
7. Efficiency Considerations
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
[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
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.
Van Rein Expires September 12, 2016 [Page 18]
Internet-Draft TLS-KDH March 2016
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.
8. Privacy Considerations
The information that is publicly shown in the TLS-KDH protocol flows
consists of:
o Supported protocol versions, TLS extensions and CipherSuites
o For other than Kerberos-only CipherSuites, the server's
Certificate
o The server's principal name, host name and service name
A 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.
9. Security Considerations
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
Van Rein Expires September 12, 2016 [Page 19]
Internet-Draft TLS-KDH March 2016
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.
10. IANA Considerations
TODO - for Kerberos:
o ChecksumTypes SHA-xxx
o AD-BACKEND-TICKETS
o KDC_ERR_INCOMPLETE_BACKEND_TICKETS
TODO - for TLS:
o ClientCertificateType "kerberos_sign"
o SignatureAlgorithm "kerberos"
o CipherSuites TLS_ECDHE_KDH_xxx
o ExtensionType for TicketRequestFlags
o TicketRequestFlags registry
11. References
11.1. Normative References
Van Rein Expires September 12, 2016 [Page 20]
Internet-Draft TLS-KDH March 2016
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510,
DOI 10.17487/RFC1510, September 1993,
<http://www.rfc-editor.org/info/rfc1510>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005,
<http://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,
<http://www.rfc-editor.org/info/rfc4343>.
[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,
<http://www.rfc-editor.org/info/rfc4492>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC6806] Hartman, S., Ed., Raeburn, K., and L. Zhu, "Kerberos
Principal Name Canonicalization and Cross-Realm
Referrals", RFC 6806, DOI 10.17487/RFC6806, November 2012,
<http://www.rfc-editor.org/info/rfc6806>.
[RFC6112] Zhu, L., Leach, P., and S. Hartman, "Anonymity Support for
Kerberos", RFC 6112, DOI 10.17487/RFC6112, April 2011,
<http://www.rfc-editor.org/info/rfc6112>.
[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,
<http://www.rfc-editor.org/info/rfc7627>.
Van Rein Expires September 12, 2016 [Page 21]
Internet-Draft TLS-KDH March 2016
11.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,
<http://www.rfc-editor.org/info/rfc2712>.
[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,
<http://www.rfc-editor.org/info/rfc3280>.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
DOI 10.17487/RFC4422, June 2006,
<http://www.rfc-editor.org/info/rfc4422>.
[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,
<http://www.rfc-editor.org/info/rfc4559>.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801,
July 2010, <http://www.rfc-editor.org/info/rfc5801>.
[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,
<http://www.rfc-editor.org/info/rfc6960>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<http://www.rfc-editor.org/info/rfc7542>.
Van Rein Expires September 12, 2016 [Page 22]
Internet-Draft TLS-KDH March 2016
Author's Address
Rick van Rein
ARPA2.net
Haarlebrink 5
Enschede, Overijssel 7544 WP
The Netherlands
Email: rick@openfortress.nl
Van Rein Expires September 12, 2016 [Page 23]