One document matched: draft-josefsson-kerberos5-starttls-08.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009, 2010 Simon Josefsson -->
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="pre5378Trust200902"
docName="draft-josefsson-kerberos5-starttls-08">
<front>
<title abbrev="Protecting Kerberos V5 with TLS">
Using Kerberos V5 over the Transport Layer Security (TLS)
protocol
</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization abbrev="SJD AB">
Simon Josefsson Datakonsult AB
</organization>
<address>
<postal>
<street>Hagagatan 24</street>
<city>Stockholm</city>
<code>113 47</code>
<country>Sweden</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<date month="January" year="2010"/>
<abstract>
<t>This document specify how the Kerberos V5 protocol can be
transported over the Transport Layer Security (TLS) protocol,
to provide additional security features.</t>
</abstract>
</front>
<middle>
<section title="Introduction and Background">
<t>This document describe how a <xref target="RFC4120">Kerberos
V5</xref> implementation may upgrade communication between
clients and Key Distribution Centers (KDCs) to use
the <xref target="RFC5246">Transport Layer Security
(TLS)</xref> protocol.</t>
<t>The TLS protocol offer integrity and privacy protected
exchanges that can be authentication using X.509
certificates, <xref target="RFC5081">OpenPGP keys</xref>, and
user name and passwords via <xref target="RFC5054">Secure
Remote Password (SRP)</xref>.</t>
<t>There are several reasons to use Kerberos V5 over TLS.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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).</t>
</list></t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Kerberos V5 STARTTLS Extension">
<t>The STARTTLS extension uses
the <xref target="RFC5021">Kerberos V5 TCP extension
mechanism</xref>. The extension uses bit #TBD in the
extension bitmask.</t>
<t>The protocol is as follows. The client requests the
extension by setting the STARTTLS bit in the TCP extension
mechanism bitmask. (How to deal with extension negotiation
failures at this point is described in <xref target="RFC5021"
/>.) 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Examples">
<t>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, and | is the binary OR operation.</t>
<figure>
<artwork>
Client Server
[ Kerberos V5 TCP extension mechanism negotiation starts ]
0x80000000 | STARTTLS-bit -------->
0x00000000
<--------
[ TLS negotiation starts ]
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ Kerberos V5 negotiation starts ]
4 octet length field
Kerberos V5 AS-REQ -------->
4 octet length field
Kerberos V5 AS-REP
<--------
* Indicates optional or situation-dependent messages that are not
always sent.
</artwork>
</figure>
</section>
<section title="STARTTLS aware KDC Discovery">
<t>Section 7.2.3 of <xref target="RFC4120">Kerberos V5</xref>
describe how <xref target="RFC2782">Domain Name System (DNS)
SRV records</xref> 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.</t>
<t>For example:</t>
<figure>
<artwork>
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
</artwork>
</figure>
</section>
<section title="Server Certificates">
<t>The TLS protocol may be used in a mode that provides server
authentication using, for example, X.509 and OpenPGP.</t>
<t>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.</t>
<t>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.</t>
<t>When clients have the ability, they MUST 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.</t>
<figure>
<artwork>
id-krb5starttls-san OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) dod(6) internet(1)
private(4) enterprise(1) gnu(11591)
shishi(6) krb5starttls-san(1) }
</artwork>
</figure>
<t>To validate a server certificate, the client MAY use local
configuration (e.g., a list that maps the Kerberos realm 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.</t>
<t>When the server presents a X.509 server certificate, clients
MAY use "Certification Path Validation" as described in
<xref target="RFC5280" /> to validate the KDC server
certificate. In addition, unless the client can otherwise
verify that the server certificate is bound to the KDC of the
target realm, the client MUST verify that the server
certificate contains the id-krb5starttls-san SAN and that the
value is identical to the intended Kerberos realm.</t>
</section>
<section title="IANA Considerations">
<t>The IANA is requested to allocate a bit in the "Kerberos TCP
Extensions" registry for the extension described in this
document, as per <xref target="RFC5021"/>.</t>
</section>
<section title="Acknowledgements">
<t>Miguel A. Garcia, Jeffrey Hutzelman, Sam Hartman, and Magnus
Nyström (in alphabetical order) provided comments that
improved the protocol and document.</t>
</section>
<section title="Security Considerations">
<t>The security considerations in Kerberos V5, TLS, and the
Kerberos V5 TCP extension mechanism are inherited.</t>
<t>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.</t>
<t>If server authentication is used, some information about the
server (such as its name) is visible to passive attackers.</t>
<t>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.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2782.xml"?>
<?rfc include="reference.RFC.4120.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.5021.xml"?>
<?rfc include="reference.RFC.5280.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.5054.xml"?>
<?rfc include="reference.RFC.5081.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 18:06:11 |