<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-miers-tls-sas-00"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="SAS for TLS">Short Authentication Strings for TLS</title>

    <author fullname="Ian Miers" initials="I" surname="Miers">
      <organization>Johns Hopkins University</organization>
      <address>
	<email>imiers@cs.jhu.edu</email>
      </address>
    </author>

    <author fullname="Matthew Green" initials="M.D." surname="Green">
      <organization>Johns Hopkins University</organization>
      <address>
	<email>mgreen@cs.jhu.edu</email>
      </address>
    </author>


    <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
      <organization>Mozilla</organization>

      <address>
        <postal>
          <street>2064 Edgewood Drive</street>

          <city>Palo Alto</city>

          <region>CA</region>

          <code>94303</code>

          <country>USA</country>
        </postal>

        <phone>+1 650 678 2350</phone>

        <email>ekr@rtfm.com</email>
      </address>
    </author>

  

    <date day="14" month="February" year="2014" />

    <area>SEC</area>

    <abstract>
      <t>
	TLS and DTLS connections generally rely on a PKI, a shared secret,
	or endpoint fingerprints for endpoint authentication. This document
	describes an authentication mechanism which instead generates
	a "short authentication string" (SAS) as an emergent property of the
	connection. The SAS can then be verified via an external channel
	in order to authenticate the connection.
      </t>
    </abstract>
  </front>
  
  <middle>

    <section title="Introduction" anchor="sec.introduction">
      <t>
	TLS <xref target="TLS12"/> and DTLS connections generally rely on a PKI, 
  a shared secret, or endpoint fingerprints for endpoint authentication. 
  This document describes an authentication mechanism which instead generates
	a "short authentication string" (SAS) as an emergent property of the
	connection. The SAS can then be verified via an external channel
	in order to authenticate the connection.
      </t>
      <t>
	While a fingerprint can be used for authentication (and is used
	in SSH), it is too long to be conveniently read and compared by two users.
	If a predictable subset of the fingerprint is compared (e.g., the first
	or last bits) an attacker can create a fingerprint which just matches
	that subset. The mechanism described by this document is based on fingerprints
	but compares a small number of bits derived from the fingerprint
  and randomness generated by both endpoints, 
  thus requiring an attacker to match the entire fingerprint (which is too long 
  to be feasible) in order to produce a low probability of detection.
	In order to compute the SAS, the endpoints run a "coin flip" protocol
	to generate a short shared bitstring which is not under the
	control of either endpoint. The bitstring is then used, along with the 
  TLS fingerprint, to derive a set of bits that are mapped to a SAS.
      </t>
    </section>

    <section anchor="sec-term" title="Terminology">
      <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="Background: Coin-Flipping Protocols" anchor="sec.coin-flip">
      <t>
	The general pattern of a coin-flipping protocol is shown below:
      </t>
      <figure>
	<artwork><![CDATA[
        Alice             Bob
        
        H(R_a) ------------->
        <---------------- R_b
        R_a ---------------->
	]]></artwork>
      </figure>
      <t>
	Alice and Bob each generate a large random number R_a and R_b.
	Alice (who speaks first) computes a commitment to R_a by hashing
	R_a and sends it to Bob. Bob then sends R_b to Alice and finally
	then Alice reveals R_a to Bob. Bob then verifies that R_a
	matches the hash Alice sent in the first message and then each
	side computes the shared value S = R_a XOR R_b.
      </t>
    </section>

    <section title="Protocol Definition" anchor="sec.proto-defn">
      <section title="Coin Flipping" anchor="sec.coin-flip-map">
	<t>
	  We map the coin flipping messages to TLS using a TLS extension
	  and a new handshake message, as shown below.
	</t>
	<figure>
	  <artwork><![CDATA[
      Client                                               Server

      ClientHello + SASXtn         -------->

                                             ServerHello + SASXtn
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      SASShare
      [ChangeCipherSpec]
      Finished                     -------->             SASShare
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data
	  ]]></artwork>
	</figure>
	<t>
	  Each side generates a 512-bit cryptographically random value
	  R_client and R_server.
	</t>
	<t>
	  The SASXtn is defined as follows:
	</t>

	<figure>
	  <artwork><![CDATA[
          struct {
              opaque digest<255>;
          } SASExtension;
	  ]]></artwork>
	</figure>
	<t>
	  The client's SASXtn is a zero-length value indicating
	  the client's desire to do the SAS handshake. The server's
	  SASXtn is a digest of R_server using the Hash defined
	  for the Finished message in Section 7.4.9 of <xref target="TLS12"/>.
	</t>
	<t>
          The SASShare structure is defined as follows:
	</t>
	<figure>
	  <artwork><![CDATA[
          struct {
              opaque share[64];
          } SASShare;
	  ]]></artwork>
	</figure>
	<t>
	  "share" is the raw byte value of R_client or R_server, as
	  appropriate. 
	</t>
      </section>

      <section title="Computing the raw SAS bits" anchor="sec.compute-subset">
	<t>
	  The SAS bits are computed as follows:
	  <list style="numbers">
	    <t>If you are the client, verify that the server's
	    R_server matches their SASExtension value. If not, abort
	    the handshake with error handshake_failure</t>
	    <t>Compute R_shared = R_client ^ R_server</t>
	    <t>  If both endpoints have certificate fingerprints compute 
        fingerprints=fingerprint_server | fingerprint_client. If only the server
        has a fingerprint, compute fingerprints=fingerprint_server.
	    </t>
      <t>Compute SAS_bits as HASH(fingerprints||R_shared) using the Hash defined
    for the Finished message in Section 7.4.9 of <xref target="TLS12"/> </t>
	  </list>
	</t>
      </section>

      <section title="Computing the SAS String" anchor="sec.compute-sas">
	<t>
    The application should map the first 15&lt;n&lt;len(fingerprints) bits of SAS_bits to some set of words or symbols defined for the application.
    One option is the PGP word list. For a spoken language agnostic  
    solution, symbols could be use.
	</t>
      </section>
    </section>
    
    <section title="Security Considerations" anchor="sec.sec-cons">
      <t>
	     Implementations MUST use fresh, random  R_client and R_server values
       for each TLS handshake.
      </t>
      <t>
        Implementations MUST ensure their share of the coin flip remains secret until after the TLS session key is established. 
      </t>
      <t>
        Applications SHOULD abort if the SAS strings do not match.
      </t>
      <t>
        Applications SHOULD abort after multiple failed TLS handshakes and notify the user.
        Failure to do so will allow an attacker multiple attempts to guess a SAS.
        They will succeed after a few thousand attempts.
      </t>

    </section>

  </middle>
  <back>
    <references title="Normative References">
      <reference anchor="RFC2119">
        <front>
          <title>
            Key words for use in RFCs to Indicate Requirement Levels
          </title>
          <author initials="S." surname="Bradner" fullname="Scott Bradner">
            <organization>Harvard University</organization>
            <address><email>sob@harvard.edu</email></address>
          </author>
          <date month="March" year="1997"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
      </reference>

      <reference anchor="TLS12">
        <front>
          <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
          <author initials="T." surname="Dierks" fullname="Tim Dierks"/>
          <author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
          <date year="2008" month="August" />
        </front>
        <seriesInfo name="RFC" value="5246" />
      </reference>
    </references>
  </back>
  </rfc>
