One document matched: draft-josefsson-kerberos5-starttls-03.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="no"?>
<?rfc toc="yes"?>

<rfc category="std" ipr="full3978"
     docName="draft-josefsson-kerberos5-starttls-03">

  <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>SJD</organization>
      <address>
	<email>simon@josefsson.org</email>
      </address>
    </author>
    
    <date month="December" year="2007"/>

    <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="RFC4346">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.<vspace blankLines="1"
	    /></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.<vspace blankLines="1" /></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.<blankLines="1" /></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.<vspace blankLines="1"
	    /></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.</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>

    </section>

    <section title="Channel Binding Pre-Authentication Data">

      <t>The pre-authentication structure is defined in RFC 4120 as:</t>

      <figure>
	<artwork>
   PA-DATA         ::= SEQUENCE {
           -- NOTE: first tag is [1], not [0]
           padata-type     [1] Int32,
           padata-value    [2] OCTET STRING -- might be encoded AP-REQ
   }
	</artwork>
      </figure>

      <t>Here we define a new pre-authentication data, called
	"pa-channel-binding".  It has a padata-type integer value of
	#TBD.  The contents of the padata-value field is the channel
	binding data, as discussed in <xref target="RFC5056"/>.</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.
	Using the terminology of Section 7.2.3 of RFC 4120, 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="Security Considerations">

      <t>The security considerations in Kerberos V5, TLS, and the
	extension mechanism framework are inherited.</t>

      <t>To protect against the inherent downgrade attack in the
	extension framework, it is suggested that implementations
	offer a policy to require that this extension is successfully
	negotiated.  For interoperability with implementations that do
	not support this extension, it is suggested that the policy is
	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.4346.xml"?>
      <?rfc include="reference.RFC.5021.xml"?>
      <?rfc include="reference.RFC.5056.xml"?>

    </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.5054.xml"?>
      <?rfc include="reference.RFC.5081.xml"?>

    </references>

  </back>

</rfc>