One document matched: draft-josefsson-krb5starttls-bootstrap-00.xml

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

<!-- Copyright (C) 2009 Simon Josefsson -->

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

<rfc category="std" ipr="trust200902" updates="4120"
     docName="draft-josefsson-krb5starttls-bootstrap-00">

  <front>

    <title abbrev="Kerberos V5 Reply Key Strengthening">
      Strengthening the Kerberos V5 Reply Key using TLS
    </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 describes how to strengthen the Kerberos V5
	reply key using keying material derived from TLS, by using a
	pre-authentication mechanism.  The goals are to 1) allow
	clients to securely learn a realm's KDC X.509 certificate, 2)
	distribute the X.509 trust anchors used by the KDC, and 3)
	make it possible for clients to use Kerberos V5 over TLS
	without having to validate the server certificates.</t>

    </abstract>

  </front>
  
  <middle>

    <section title="Introduction and Background">

      <t>This document describes a <xref target="RFC4120">Kerberos
	V5</xref> pre-authentication mechanism that
	uses <xref target="I-D.josefsson-kerberos5-starttls">Kerberos
	V5 over TLS</xref> to achieve:</t>

      <t><list style="symbols">

	  <t>Allow Kerberos V5 clients to securely learn a Kerberos V5
	    realm's Key Distribution Center (KDC) certificates.  This
	    is achieved by having the client connect to a KDC, take a
	    note of the server's certificate, and verify them as
	    belonging to the KDC the user trusts by properly
	    decrypting the Kerberos V5 response using the user's
	    password.  Only the correct KDC will be able to generate a
	    Kerberos V5 response using the user's password and the
	    secrets derived from the TLS channel.</t>

	  <t>Securely distribute the trust anchors used by the Key
	    Distribution Center (KDC) in a Kerberos V5 realm.  This is
	    achieved the same way as before, but rather than
	    remembering the server certificate, it remembers the trust
	    anchor.</t>

	  <t>The ability to use Kerberos V5 over TLS without having to
	    validate the server certificates.</t>

      </list></t>

      <t>The mechanism to achieve the above goals is for the KDC to
	strengthen the Kerberos V5 reply key using keying material
	derived from the <xref target="RFC5246">TLS channel</xref>
	using the algorithm specified
	in <xref target="I-D.ietf-tls-extractor">Keying Material
	Exporters for Transport Layer Security (TLS)</xref>.</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="Protocol">

      <t>The client and KDC MUST
	support <xref target="I-D.josefsson-kerberos5-starttls">Kerberos
	V5 over TLS</xref>.  If the client do not (yet) have trust
	anchors for the KDC, it should disable verification of the
	server certificate.</t>

      <t>To signal that the client wishes the KDC to strengthen the
	reply key using keying material derived from the TLS session,
	it sends a pre-authentication mechanism called
	"pa-krb5starttls-bootstrap".  It has a pdata-type integer
	value of #TBD.</t>

      <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>The content of the padata-value should be the DER encoding of
	the empty string.</t>

      <t>When receiving the request to use the
	"pa-krb5starttls-bootstrap" pre-authentication message, the
	KDC needs to decide whether to honor it or not.  This is a
	policy decision that can depend on several reasons, including
	the content of the request.  If the KDC decides that it does
	not wish to honor the "pa-krb5starttls-bootstrap" request, the
	KDC MUST fail the request by returning
	KDC_ERR_PREAUTH_FAILED.</t>

      <t>When the KDC decides to honor the client's request, it will
	process the incoming request as usual except that the KDC-REP
	reply key is post processed as follows.  The post processing
	uses <xref target="I-D.ietf-tls-extractor">Keying Material
	Exporters for Transport Layer Security (TLS)</xref>.  The
	channel binding input "tlscb" value MUST be the client's TLS
	Finished message data as described in the "tls-unique" channel
	binding registration.</t>

      <figure>
	<artwork>
   StrengthenKrb5ReplyKeyUsingTLS (inkey, inkey_len,
                                   tlscb, tlscb_len)

   Input:          inkey      encryption key, an octet string
                   inkey_len  length of encryption key,
                              a positive integer
                   tlscb      channel binding data, an octet string,
                   tlscb_len  length of channel binding data,
                              a positive integer

   Output:         outkey   derived key, a inlen-octet string

   Steps:

      1. Perform the TLS Exporter step:

          outkey = PRF(master_secret, label,
                       SecurityParameters.client_random +
                       SecurityParameters.server_random +
                       context_value_length + context_value
                      )[length]

         The "context_value" should be the concatenation of "inkey"
         followed by "tlscb".

         Consequently, the length of "context_value" (which used to
         derived "context_value_length") will be the sum of
         "inkey_len" and "tlscb_len".

         Use the value of "inkey_len" as the value of the "length"
         variable.

      3. Output the derived key "outkey".
	</artwork>
      </figure>

      <t>The client will strengthen the KDC-REP reply key using the
	same procedure.</t>

      <t>On successful decryption of the KDC-REP, the clients is
	certain that it is talking to a KDC that knows the client's
	shared key without any man-in-the-middle.  The client can then
	remember the KDC server certificate and/or trust anchors
	transferred during the TLS handshake, to be used during future
	Kerberos V5 over TLS connections.  The client MAY skip using
	this protocol for future connections, and instead rely on the
	standard Kerberos V5 over TLS protocol with proper validation
	of server certificate.</t>

    </section>

    <section title="IANA Considerations">

      <t>None.</t>

    </section>

    <section title="Acknowledgements">

      <t>Nicolas Williams mentioned the advantages in
	<http://permalink.gmane.org/gmane.ietf.krb-wg/5016>.</t>

    </section>

    <section title="Security Considerations">

      <t>The security considerations
	in <xref target="RFC4120">Kerberos V5</xref>,
	<xref target="RFC5246">TLS</xref>, <xref target="RFC5021">Kerberos
	V5 TCP extension</xref>,
	and <xref target="I-D.josefsson-kerberos5-starttls">Kerberos
	V5 over TLS</xref> are inherited.</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.4120.xml"?>
      <?rfc include="reference.I-D.josefsson-kerberos5-starttls"?>
      <?rfc include="reference.I-D.ietf-tls-extractor.xml"?>

    </references>

    <references title="Informative References">

      <?rfc include="reference.RFC.5021.xml"?>
      <?rfc include="reference.RFC.5246.xml"?>

    </references>

  </back>

</rfc>