One document matched: draft-thomson-mmusic-fingerprint-00.xml

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" docName="draft-thomson-mmusic-fingerprint-00" updates="4572">
  <front>
    <title abbrev="SDP Certificate Fingerprints">
      Use of Fingerprints for Identifying Certificates in the Session Description Protocol (SDP)
    </title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Microsoft</organization>
      <address>
        <postal>
          <street>3210 Porter Drive</street>
          <city>Palo Alto</city>
          <region>CA</region>
          <code>94304</code>
          <country>US</country>
        </postal>

        <email>martin.thomson@skype.net</email>
      </address>
    </author>

    <date year="2013"/>
    <area>Application</area>
    <workgroup>MMUSIC</workgroup>
    <keyword>Internet-Draft</keyword>
    <keyword>Fingerprint</keyword>
    <keyword>SDP</keyword>
    <keyword>Certificate</keyword>
    <keyword>Hash</keyword>

    <abstract>
      <t>
        The Session Description Protocol (SDP) fingerprint attribute binds a session description to
        an X.509 certificate.  This document describes how hash agility is achieved without
        backwards compatibility issues.  This document also describes how the fingerprint attribute
        can be used to identify a set of valid certificates.
      </t>
      <t>
        This document updates RFC4572.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="intro" title="Introduction">
      <t>
        <xref target="RFC4572">RFC 4572</xref> describes how the fingerprint <xref
        target="RFC4566">Session Description Protocol (SDP)</xref> attribute binds a session
        description to an <xref target="X509">X.509 certificate</xref>.  Unfortunately, the only
        statement it makes regarding multiple fingerprints is the following:
        <list>
          <t>
            A certificate fingerprint MUST be computed using the same one-way hash function as is
            used in the certificate's signature algorithm.
          </t>
        </list>
      </t>
      <t>
        This has the unfortunate consequence of unnecessarily coupling the security properties of
        the certificate to the hash function used in signing the certificate.  To maximize the
        chances of a certificate being accepted, the hash algorithm used in certificates tends to
        lag current best practice, potentially exposing sessions to attacks based on hash collision.
      </t>
      <t>
        The ability to use stronger cryptographic hash algorithms (hash agility) improves the
        integrity of the binding between the session description and the entity in possession of the
        private key.  Systems that rely on other bindings to the session (or the private keys used
        to establish it) do not benefit from these changes.
      </t>
      <t>
        This document also describes an optional mechanism that might be used to identify multiple
        certificates, in cases where the offered certificate might be selected from a small set.
        This might have operational advantages where the endpoint answering a call is not known
        ahead of a session description being created.
      </t>

      <section anchor="terminology" title="Conventions and Terminology">
       <t>
         At times, this document falls back on shorthands for establishing interoperability
         requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY".  These
         terms are defined in <xref target="RFC2119"/>.
       </t>
      </section>
    </section>

    <section anchor="agility" title="Hash Agility">
      <t>
        The SDP fingerprint attribute is used to indicate the hash of the certificate - a
        certificate fingerprint - that is offered in the <xref target="RFC5246">TLS</xref> or <xref
        target="RFC5764">DTLS</xref> handshake.  The certificate fingerprint so included is used to
        bind the (D)TLS session to the session description.
      </t>
      <t>
        Multiple fingerprint attributes can be used to identify a certificate using alternative
        cryptographic hash algorithms.  This allows sessions descriptions to use alternative,
        potentially stronger, hash algorithms without risking interoperability failure.  A stronger
        hash algorithm is more resistant to collision attacks, which can be used to impersonate
        endpoints.
      </t>
      <t>
        To avoid cases where certificate fingerprints cannot be validated, implementations MUST
        support <xref target="FIPS2">SHA-256</xref>.  That is, a fingerprint attribute using SHA-256
        MUST be included in any place that includes fingerprint attributes and implementations MUST
        be able to validate SHA-256 fingerprints.
      </t>
      <t>
        Implementations or specific applications can specify that validation using a different hash
        algorithm be mandatory in order to achieve a desired level of collision resistance.
        Implementations MUST NOT consider a session binding to be valid unless a certificate
        fingerprint using sufficiently strong hash algorithm matches one in the session description.
        For example, an application might specify that certificates are validated using <xref
        target="FIPS2">SHA-384</xref> in addition to, or instead of, SHA-256.
      </t>
      <t>
        Additional fingerprint attributes MAY be included using alternative hash algorithms.  An
        endpoint that validates a session using fingerprint attributes MUST report failure if any
        hash that it checks doesn't match.
      </t>
      <t>
        Endpoints can ignore fingerprint attributes that use hash algorithms it doesn't support or
        wish to validate.
      </t>
    </section>

    <section anchor="multiples" title="Multiple Certificates">
      <t>
        <cref>It's unclear whether this feature is desirable.  This is included purely as a strawman
        to aid discussion.</cref>
      </t>
      <t>
        It might be that an application desires the ability to create session descriptions where the
        security context can be terminated using one of a small set of certificates.
      </t>
      <t>
        An endpoint that validates a session description with multiple values for the same hash
        algorithm MUST fail the validation unless a fingerprint matches for each hash algorithm
        validated.  Therefore, a session description that includes multiple a=fingerprint values for
        the same hash algorithm MUST include the same number of a=fingerprint values for every hash
        algorithm that is included.
      </t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>
        Over time, advances in cryptanalysis and computational power render hash algorithms
        increasingly prone to collision attacks.  A hash collision on a certificate fingerprint
        would allow for impersonation.  This document describes how to use different hash
        algorithms, independent of those selected for use in certificates.
      </t>
      <t>
        Hash agility does not reduce the need for session description integrity protection or any of
        the suggested supporting mechanisms described in <xref target="RFC4572"/>.
      </t>
      <t>
        Adding support for hash agility does not affect the properties gained through the use of
        other mechanisms like the use of other bindings between session and identity.  This document
        only improves the binding between a session and its description in SDP.  For example,
        mechanisms such as the one described in <xref target="I-D.ietf-rtcweb-security-arch"/>
        require the implementation of equivalent processing rules to benefit from hash agility.
        Systems relying on the X.509 certificate chain to a specific trust anchor are similarly
        unaffected.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <t>
        This document has no IANA actions.
      </t>
      <t>
        <cref>It might, if we decide that adding a reference to this document from the a=fingerprint
        registration is sensible.</cref>
      </t>
    </section>

    <section anchor="ack" title="Acknowledgements">
      <t>
        Kevin Dempsey raised the original question that motivated this draft.
      </t>
    </section>

    <!--
        <appendix title="Change Log">
        <t>[[The RFC Editor is requested to remove this section at publication.]]</t>
        <t>Changes since -0-1:
        <list style="symbols">
        <t>Document created.</t>
        </list>
        </t>
        </appendix>
    -->
  </middle>

  <back>

    <references title="Normative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml"?>
      <reference anchor="FIPS2">
        <front>
          <title>
            Secure Hash Standard
          </title>
          <author fullname="National Institute of Standards and Technology">
          </author>
          <date month="August" year="2002"/>
        </front>
        <seriesInfo name="FIPS PUB" value="180-2"/>
        <seriesInfo name="ISO Standard" value="9594-8"/>
      </reference>
      <reference anchor="X509">
        <front>
          <title>
            Information technology - Open Systems Interconnection - The Directory: Public-key and
            attribute certificate frameworks
          </title>
          <author fullname="International Telecommunications Union">
          </author>
          <date month="March" year="2000"/>
        </front>
        <seriesInfo name="ITU-T Recommendation" value="X.509"/>
        <seriesInfo name="ISO Standard" value="9594-8"/>
      </reference>
    </references>
    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security-arch.xml"?>
    </references>
  </back>
</rfc>