Using Kerberos V5 over the Transport Layer Security (TLS)
protocol
Simon Josefsson Datakonsult AB
Hagagatan 24Stockholm113 47Swedensimon@josefsson.orghttp://josefsson.org/This document specify how the Kerberos V5 protocol can be
transported over the Transport Layer Security (TLS) protocol,
to provide additional security features. This document
updates RFC 4120.This document describe how a Kerberos
V5 implementation may upgrade communication between
clients and Key Distribution Centers (KDCs) to use
the Transport Layer Security
(TLS) protocol.The TLS protocol offer integrity and privacy protected
exchanges that can be authentication using X.509
certificates, OpenPGP keys, and
user name and passwords
via SRP.There are several reasons to use Kerberos V5 over TLS.Prevents downgrade attacks affecting, e.g., encryption
types and pre-auth data negotiation. The encryption type
field in KDC-REQ, and the METHOD-DATA field with the
requested pre-auth types from the server in
KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
without integrity or privacy protection in Kerberos 5.
This allows an active attacker to replace the encryption
type with a compromised encryption type, e.g., 56-bit DES,
or request that clients should use a broken pre-auth type.
Since clients in general cannot know the encryption types
other servers support, or the pre-auth types servers
prefer or require, it is difficult for the client to
detect if there was a man-in-the-middle or if the remote
server simply did not support a stronger encryption type
or preferred another pre-auth type.Kerberos exchanges are privacy protected. Part of many
Kerberos packets are transferred without privacy protection
(i.e., encryption). That part contains information, such as
the client principal name, the server principal name, the
encryption types supported by the client, the lifetime of
tickets, etc. Revealing such information is, in some threat
models, considered a problem.Additional authentication against the KDC. In some
situations, users are equipped with smart cards with a RSA
authentication key. In others, users have a OpenPGP
client on their desktop, with a public OpenPGP key known
to the server.The TLS protocol has been studied by many parties. In
some threat models, the designer prefer to reduce the
number of protocols that can hurt the overall system
security if they are compromised.Explicit server authentication of the KDC to the client.
In traditional Kerberos 5, authentication of the KDC is
proved as a side effect that the KDC knows your encryption
key (i.e., your password).The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119.The STARTTLS extension uses
the Kerberos V5 TCP extension
mechanism. The extension uses bit #TBD in the
extension bitmask.The protocol is as follows. After the server has sent the
4-octet value 0x00000000 to indicate support of this
extension, the stream will be controlled by the TLS protocol
and its framing. The TLS protocol is initiated by the
client.Typically, the client initiate the TLS handshake protocol by
sending a client hello, and the server responds, and the
handshake continues until it either succeed or fails.If for any reason the handshake fails, the STARTTLS protocol
will also fail, and the TLS error is used as the error
indication. In this case, no further messages can be
exchanged over the same TCP session.If the handshake succeeds, the Kerberos V5 authentication
protocol is performed within the protected TLS channel, like a
normal TCP Kerberos V5 exchange. In particular, this means
that every Kerberos V5 packet will be prefixed by a 4-octet
length field, that indicate the length of the Kerberos V5
packet.When no further Kerberos V5 messages needs to be transferred
in the TLS session, the TLS session MUST be shut down properly
using the close_notify alert. When the TLS session is shut
down, the TCP connection cannot be re-used to send any further
data and MUST be closed.A complete packet flow for a successful AS-REQ/REP exchange
protected by this mechanism will be as follows. The
"STARTTLS-bit" is a 4-octet value with only the bit allocated
for this extension set.Section 7.2.3 of Kerberos V5
describe how Domain Name System (DNS)
SRV records can be used to find the address of an KDC.
We define a new Proto of "tls" to indicate that the particular
KDC is intended to support this STARTTLS extension. The
Service, Realm, TTL, Class, SRV, Priority, Weight, Port and
Target have the same meaning as in RFC 4120.For example:The TLS protocol can provide server authentication using, for
example, X.509 and OpenPGP. By validating the server
certificate, clients can be certain that it is talking to the
intended KDC.The Kerberos V5 STARTTLS protocol do not require clients to
verify the server certificate. The goal is that support for
TLS in Kerberos V5 clients should be as easy to implement and
deploy as support for UDP/TCP. Use of TLS, even without
server certificate validation, protects against some attacks
that Kerberos V5 over UDP/TCP do not. Requiring server
certificates to be used at all times would enable attacks in
those situations.Many clients does not have secure long-term storage that is
required to validate certificates. This makes it impossible
to implement server certificate validation in practice on a
large number of deployed systems.When clients have the ability, they need to be able to
validate the server certificate. For this reason, if a KDC
presents a X.509 server certificate over TLS, it MUST contain
an otherName Subject Alternative Name (SAN) identified using a
type-id of id-krb5starttls-san. The intention is to bind the
server certificate to the Kerberos realm for the purpose of
using Kerberos V5 STARTTLS. The value field of the otherName
should contain the realm as the "Realm" ASN.1 type.To validate a server certificate, the client MAY use local
configuration (e.g., a list that map realm names to a copy of
the server's certificate) and compare that with the
authentication information provided from the server via TLS.
For illustration, the server certificate could be a X.509
certificate or an OpenPGP key. In this mode, the client need
no processing related to id-krb5starttls-san.When the server presents a X.509 server certificate, there is
an alternative way that clients MAY use to validate the server
certificate. In this mode, the KDC server certificate is
validated by "Certification Path Validation" as described in
. In addition, the client MUST
verify that the server certificate contains the
id-krb5starttls-san SAN and that the value is identical with
the intended Kerberos realm.The IANA is requested to allocate a bit in the "Kerberos TCP
Extensions" registry for the extension described in this
document, as per .Jeffrey Hutzelman and Sam Hartman provided comments that
improved the protocol and document.The security considerations in Kerberos V5, TLS, and the
Kerberos V5 TCP extension mechanism are inherited.Note that TLS does not protect against Man-In-The-Middle
(MITM) attacks unless clients verify the KDC's credentials
(X.509 certificate, OpenPGP key, etc) correctly.To protect against the inherent downgrade attack in the
extension framework, implementations SHOULD offer a policy
mode that requires this extension to always be successfully
negotiated, for a particular realm, or generally. For
interoperability with implementations that do not support this
extension, the policy mode SHOULD be disabled by default.