One document matched: draft-josefsson-kerberos5-starttls-05.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- Copyright (C) 2004, 2005, 2006, 2007, 2008, 2009 Simon Josefsson -->
<?rfc compact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="pre5378Trust200902" updates="4120"
docName="draft-josefsson-kerberos5-starttls-05">
<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="March" year="2009"/>
<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. This document
updates RFC 4120.</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">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 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 transfered 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>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.</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. 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. However, to conform with this specification, any
KDC-REQ (AS-REQ or TGS-REQ) message MUST contain the
"pa-channel-binding" pre-authentication data.</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 furhter
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.</t>
<figure>
<artwork>
Client Server
[ Kerberos V5 TCP extension mechanism negotiation starts ]
[0x70000000 & 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="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>Jeffrey Hutzelman provided comments that improved the
protocol and document.</t>
</section>
<section title="Security Considerations">
<t>The security considerations in Kerberos V5, TLS, and the
extension mechanism framework 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>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"?>
</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:12:44 |