Technical Summary
This document specify how the Kerberos V5 protocol can be transported
over the Transport Layer Security (TLS) protocol, to provide
additional security features.
Working Group Summary
This technical specification represents the consensus of the
Kerberos Working Group. However, the working group is also
working on an alternate solution to an overlapping problem. It
is not yet clear whether either or both specifications will win
in the marketplace or whether either will become mandatory in a
future version of the base Kerberos specification. However, we
feel it is important to publish these specifications to gain
implemention and deployment experience. Therefore, we are
requesting publication of this document as an Informational RFC,
and may request that it be upgraded to Proposed Standard at a
later time.
Document Quality
At least one implementor has indicated an intention to support
the extension described in this document.
Personnel
The Document Shepherd for this document is Jeffrey Hutzelman.
The responsible Area Director is Tim Polk.
RFC Editor Note
In Section 4, change:
OLD:
Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
System (DNS) SRV records [RFC2782] 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:
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
NEW:
Section 7.2.3 of Kerberos V5 [RFC4120] describe how Domain Name
System (DNS) SRV records [RFC2782] can be used to find the address of
an KDC. We define a new Service of "kerberos-tls" to indicate that the
particular KDC is intended to support this STARTTLS extension. The
Proto (tcp), Realm, TTL, Class, SRV, Priority, Weight, Port and Target
have the same meaning as in RFC 4120.
For example:
_kerberos-tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos-tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
In Section 5, please make the following substitution:
OLD
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.
(For example, passive network sniffing between the user and the KDC
to track which Kerberos services are used by the user.) To require
server certificates to be validated at all times would lead to
disabling of TLS when clients are unable to validate server
certificates, and this may have worse security properties than using
TLS and not validate the server certificate would have.
Many client environments do not have secure long-term storage, which
is required to validate certificates. This makes it impossible to
use server certificate validation on a large number of client
systems.
NEW
A goal for the protocol described in this memo is that it should be as
easy to implement and deploy on clients as support for UDP/TCP. Since
many client environments do not have secure long-term storage (and
server certificate validation requires some form of long-term
storage), the Kerberos V5 STARTTLS protocol does not require clients
to verify server certificates. If server certification had been
required, then environments with constrained clients such as those
mentioned would be forced to disable TLS; this would arguably be worse
than TLS without server certificate validation as use of TLS, even
without server certificate validation, protects against some attacks
that Kerberos V5 over UDP/TCP do not. For example, even without server
certificate validation, TLS does protect against passive network
sniffing aimed at tracking Kerberos service usage by a given client.
Note however that use of TLS without server certificate verification
opens up for a range of active attacks such as man-in-the-middle.
In order to safely validate certificates, a client needs access to
secure long-term storage. However, many client environments do not
provide secure long-term storage (e.g., because the machine has been
compromised). This makes it impossible to use server certificate
validation on a large number of client systems.