One document matched: draft-thomson-http2-client-certs-00.xml

<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.0.20 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<rfc ipr="trust200902" docName="draft-thomson-http2-client-certs-00" category="std" updates="7450">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title abbrev="HTTP/2 Client Certs">Reactive Certificate-Based Client Authentication in HTTP/2</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>
    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Microsoft</organization>
      <address>
        <email>michael.bishop@microsoft.com</email>
      </address>
    </author>

    <date year="2015"/>

    <area>General</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>Some HTTP servers provide a subset of resources that require additional
authentication to interact with.  HTTP/1.1 servers rely on TLS renegotiation
that is triggered by a request to a protected resource.  HTTP/2 made this
pattern impossible by forbidding the use of TLS renegotiation.</t>

<t>This document describes a how client authentication might be requested by a
server as a result of receiving a request to a protected resource.  This
document updates RFC 7540 to allow TLS renegotiation in limited circumstances.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Many existing HTTP <xref target="RFC7230"></xref> servers have different authentication requirements
for the different resources they serve.  Of the bountiful authentication options
available for authenticating HTTP requests, client certificates present a unique
challenge for resource-specific authentication requirements because of the
interaction with the underlying TLS <xref target="I-D.ietf-tls-tls13">RFC5246</xref> layer.</t>

<t>For servers that wish to use client certificates to authenticate users, they
might request client authentication during the TLS handshake.  However, if not
all users or resources need certificate-based authentication, a request for a
certificate has the unfortunate consequence of triggering the client to seek a
certificate.  Such a request can result in a poor experience, particular when
sent to a client that does not expect the request.</t>

<t>The TLS CertificateRequest can be used by servers to give clients hints about
which certificate to offer.  Servers that rely on certificate-based
authentication might request different certificates for different resources.
Such a server cannot use contextual information about the resource to construct
an appropriate TLS CertificateRequest message during the initial handshake.</t>

<t>Consequently, client certificates are requested at connection establishment time
only in cases where all clients are expected or required to have a single
certificate that is used for all resources.  Many other uses for client
certificates are reactive, that is, certificates are requested in response to
the client making a request.</t>

<t><list style="hanging">
  <t hangText='CAVEAT:'>
  As of 2015-10-02, TLS 1.3 does not include the client authentication features
this draft relies on.  While these features have been agreed in the TLS
working group, the exact design is still under revision.  The basic
functionality shouldn’t change in a way that will affect this document, though
some details such as field names are highly likely to change.</t>
</list></t>

<section anchor="reactive-certificate-authentication-in-http11" title="Reactive Certificate Authentication in HTTP/1.1">

<t>In HTTP/1.1, a server that relies on client authentication for a subset of users
or resources does not request a certificate when the connection is established.
Instead, it only requests a client certificate when a request is made to a
resource that requires a certificate.</t>

<t><xref target="ex-http11"/> shows the server initiating a TLS-layer renegotiation in response
to receiving an HTTP/1.1 request to a protected resource.</t>

<figure title="HTTP/1.1 Reactive Certificate Authentication with TLS 1.2" anchor="ex-http11"><artwork><![CDATA[
Client                                      Server
   -- (HTTP) GET /protected -------------------> *1
   <---------------------- (TLS) HelloRequest -- *2
   -- (TLS) ClientHello ----------------------->
   <------------------ (TLS) ServerHello, ... --
   <---------------- (TLS) CertificateRequest -- *3
   -- (TLS) ..., Certificate ------------------> *4
   -- (TLS) Finished -------------------------->
   <-------------------------- (TLS) Finished --
   <--------------------------- (HTTP) 200 OK -- *5
]]></artwork></figure>

<t>In this example, the server receives a request for a protected resource (at *1
on <xref target="ex-http11"/>).  Upon performing an authorization check, the server
determines that the request requires authentication using a client certificate
and that no such certificate has been provided.</t>

<t>The server initiates TLS renegotiation by sending a TLS HelloRequest (at *2).
The client then initiates a TLS handshake.  Note that some TLS messages are
elided from the exchange for the sake of brevity.</t>

<t>The critical messages for this example are the server requesting a certificate
with a TLS CertificateRequest (*3); this request might use information about
the request or resource.  The client then provides a certificate and proof of
possession of the private key in Certificate and CertificateVerify messages (*4).</t>

<t>When the handshake completes, the server performs any authorization checks a
second time.  With the client certificate available, it then authorizes the
request and provides a response (*5).</t>

</section>
<section anchor="tls-13-client-authentication" title="TLS 1.3 Client Authentication">

<t>TLS 1.3 <xref target="I-D.ietf-tls-tls13"></xref> introduces a new client authentication mechanism
that allows for clients to authenticate after the handshake has been completed.
For the purposes of authenticating an HTTP request, this is functionally
equivalent to renegotiation.  <xref target="ex-tls13"/> shows the simpler exchange this
enables.</t>

<figure title="HTTP/1.1 Reactive Certificate Authentication with TLS 1.3" anchor="ex-tls13"><artwork><![CDATA[
Client                                      Server
   -- (HTTP) GET /protected ------------------->
   <---------------- (TLS) CertificateRequest --
   -- (TLS) Certificate ----------------------->
   <--------------------------- (HTTP) 200 OK --
]]></artwork></figure>

<t>TLS 1.3 does not support renegotiation, instead supporting direct client
authentication.  In contrast to the TLS 1.2 example, in TLS 1.3, a server can
simply request a certificate.</t>

</section>
<section anchor="reactive-client-authentication-in-http2" title="Reactive Client Authentication in HTTP/2">

<t>An important part of the HTTP/1.1 exchange is that the client is able to easily
identify the request that caused the TLS renegotiation.  The client is able to
assume that the next unanswered request on the connection is responsible.  The
HTTP stack in the client is then able to direct the certificate request to the
application or component that initiated that request.  This ensures that the
application has the right contextual information for processing the request.</t>

<t>In HTTP/2, a client can have multiple outstanding requests.  Without some sort
of correlation information, a client is unable to identify which request caused
the server to request a certificate.</t>

<t>Thus, the minimum necessary mechanism to support reactive certificate
authentication in HTTP/2 is an identifier that can be use to correlate an HTTP
request with either a TLS renegotiation or CertificateRequest.</t>

<t><xref target="aci-13"/> describes how the existing TLS 1.3 fields and a new HTTP/2 frame
described in <xref target="frame"/> can be used to correlate a request with a TLS
CertificateRequest.  <xref target="aci-12"/> describes how the same can be
done in TLS 1.2 using TLS renegotiation and a new TLS <spanx style="verb">application_context_id</spanx>
extension.  Finally, <xref target="setting"/> describes how an HTTP/2 client can announce
support for this feature so that a server might use these capabilities.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>RFC 2119 <xref target="RFC2119"></xref> defines the terms “MUST”, “MUST NOT”, “SHOULD” and “MAY”.</t>

</section>
</section>
<section anchor="aci-13" title="HTTP/2 Request Correlation in TLS 1.3">

<t>An HTTP/2 request from a client that has signaled support for reactive
certificate authentication (see <xref target="setting"/>) might cause a server to request
client authentication.  In TLS 1.3 a server does this by sending a new TLS 1.3
CertificateRequest.</t>

<t>The server MUST first send a WAITING_FOR_AUTH frame (see <xref target="frame"/>) on the
stream which triggered the request for client credentials.  The
certificate_request_id (name TBD) field of the TLS CertificateRequest is
populated by the server with the same value in the WAITING_FOR_AUTH frame.
Subsequent WAITING_FOR_AUTH frames with the same request identifier MAY be sent
on other streams while the server is awaiting client authentication with the
same parameters.  This allows a client to correlate the TLS CertificateRequest
with one or more outstanding requests.</t>

<t>A server MAY send multiple concurrent TLS CertificateRequest messages.  If a
server requires that a client provide multiple certificates before authorizing a
single request, it MUST send WAITING_FOR_AUTH frames with different request
identifiers before sending subsequent TLS CertificateRequest messages.</t>

</section>
<section anchor="aci-12" title="HTTP/2 Request Correlation in TLS 1.2">

<t>An HTTP/2 server that uses TLS 1.2 initiates client authentication by sending a
an HTTP/2 WAITING_FOR_AUTH frame followed by a TLS HelloRequest.  This triggers
a TLS renegotiation.</t>

<t>An HTTP/2 client that receives a TLS HelloRequest message MUST initiate a TLS
handshake, including an empty <spanx style="verb">application_context_id</spanx> extension.  If the client
has not indicated support for renegotiation (see <xref target="setting"/>), the client MUST
send a fatal TLS <spanx style="verb">no_renegotiation</spanx> alert.</t>

<t>The server populates the <spanx style="verb">application_context_id</spanx> extension with the same value
it previously sent in a WAITING_FOR_AUTH frame.</t>

<t>Absence of an <spanx style="verb">application_context_id</spanx> extension or an empty value from the
server MUST be treated as a fatal error; endpoints MAY send a fatal TLS
<spanx style="verb">no_renegotiation</spanx> alert.</t>

<t>As with the TLS 1.3 solution, a server MAY request multiple client certificates,
either for different requests or for the same request.  If multiple requests are
waiting for authentication and require different certificates, the server SHOULD
immediately send the WAITING_FOR_AUTH frames with unique values.  Only one TLS
renegotiation can be in progress at a time, though a new HelloRequest can be
emitted once the renegotiation has completed.</t>

<t>A server MAY treat all certificates presented in the same connection as
cumulative, remembering multiple certificates as they are presented.  Note that
the authentication information collected from the client will need to be checked
after each TLS renegotiation completes, since most TLS stacks only report the
presence of the client certificate presented during the last TLS handshake.</t>

<section anchor="extension" title="The TLS application_context_id Hello Extension">

<t>The <spanx style="verb">application_context_id</spanx> TLS Hello Extension is used to carry an identifier
from an application context in the TLS handshake.  This is used to identify the
application context that caused the TLS handshake to be initiated.  The
semantics of the field depend on application protocol, and could further depend
on application protocol state.</t>

<t>Either client or server can populate this field.  A client can provide an empty
value to indicate that it does not know the application context, but would like
the server to provide a value.  A server can provide an empty value in response
to a non-empty value only.</t>

<t>In HTTP/2 clients always provide an empty <spanx style="verb">application_context_id</spanx> value, and
servers always provide a value that will appear in a subsequent WAITING_FOR_AUTH
frame.</t>

<figure title="The application_context_id Extension Format" anchor="acid-extension"><artwork><![CDATA[
enum {
    ...
    application_context_id(EXTENSION-TBD),
    (65535)
} ExtensionType;

struct {
    opaque id<0..255>;
} ApplicationContextId;
]]></artwork></figure>

</section>
<section anchor="update" title="Permitting TLS Renegotiation in HTTP/2">

<t>The prohibition from Section 9.2.1 of <xref target="RFC7540"></xref> against TLS renegotiation is
removed, provided that the requirements of this section are adhered to.</t>

<t>TLS renegotiation MUST NOT be used to circumvent the other restrictions on TLS
use from Section 9.2 of <xref target="RFC7540"></xref>.  Furthermore, TLS renegotiation MUST
negotiate the same ALPN <xref target="RFC7301"></xref> identifier (that is, “h2”).  An endpoint MAY
treat failure to comply with these requirements as a connection error (Section
5.4.1 of <xref target="RFC7540"></xref>) of type INADEQUATE_SECURITY.</t>

<t><list style="hanging">
  <t hangText='Note:'>
  A client need not offer cipher suites that might otherwise be offered for
compatibility reasons when renegotiating.  In particular, cipher suites on the
black list from Appendix A of <xref target="RFC7540"></xref> can be removed from the handshake.</t>
</list></t>

<t>In addition to the requirements from <xref target="RFC7540"></xref>, endpoints that renegotiate MUST
implement the TLS extended master secret extension <xref target="RFC7627"></xref> and the TLS
renegotiation indication extension <xref target="RFC5746"></xref>.  These extensions MUST be
negotiated and used to prevent serious attacks on TLS renegotiation.  If an
endpoint receives a TLS ClientHello or ServerHello that does not include these
extensions, it MUST respond with a fatal TLS <spanx style="verb">no_renegotiation</spanx> alert.</t>

<t>The TLS renegotiation handshake MUST include the <spanx style="verb">application_context_id</spanx>
extension when used with HTTP/2.</t>

<t>A server MUST present the same certificate during TLS renegotiation it used
during the initial handshake.  Clients MUST verify that the server certificate
does not change.  Clients MUST verify that the server certificate has not
changed; a different certificate MUST be treated as a fatal error and MAY cause
a fatal <spanx style="verb">handshake_failure</spanx> alert to be sent.</t>

<t>Once the HTTP/2 connection preface has been received from a peer, an endpoint
SHOULD treat the receipt of a TLS ClientHello or ServerHello without an
<spanx style="verb">application_context_id</spanx> extension as a fatal error and SHOULD send a fatal TLS
<spanx style="verb">no_renegotiation</spanx> alert.</t>

</section>
</section>
<section anchor="frame" title="Indicating Stream Dependency on Certificate Authentication">

<t>The WAITING_FOR_AUTH frame (0xFRAME-TBD) is sent by servers to indicate that
processing of a request is blocked pending authentication outside of the HTTP
channel. The frame includes a request identifier which can be used to correlate
the stream with challenges for authentication received at other layers, such as
TLS.</t>

<t>The WAITING_FOR_AUTH frame contains between 1 and 255 octets, which is the
authentication request identifier.  A client that receives a WAITING_FOR_AUTH of
any other length MUST treat this as a stream error of type PROTOCOL_ERROR.
Frames with identical request identifiers refer to the same TLS
CertificateRequest.</t>

<t>The WAITING_FOR_AUTH frame MUST NOT be sent by clients.  A WAITING_FOR_AUTH
frame received by a server SHOULD be rejected with a stream error of type
PROTOCOL_ERROR.</t>

<t>The server MUST NOT send a WAITING_FOR_AUTH frame on stream zero, a
server-initiated stream or a stream that does not have an outstanding request.
In other words, a server can only send in the “open” or “half-closed (remote)”
stream states.</t>

<t>A client that receives a WAITING_FOR_AUTH frame on a stream which is not in a
valid state (“open” or “half-closed (local)” for clients) SHOULD treat this as a
connection error of type PROTOCOL_ERROR.</t>

</section>
<section anchor="setting" title="Indicating Support for Reactive Certificate Authentication">

<t>Clients that support reactive certificate authentication indicate
this using the HTTP/2 <spanx style="verb">SETTINGS_REACTIVE_AUTH</spanx> (0xSETTING-TBD) setting.</t>

<t>The initial value for the <spanx style="verb">SETTINGS_REACTIVE_AUTH</spanx> setting is 0, indicating that
the client does not support reactive client authentication.  A client sets the
<spanx style="verb">SETTINGS_REACTIVE_AUTH</spanx> setting to a value of 1 to indicate support for
reactive certificate authentication as defined in this document.  Any value
other than 0 or 1 MUST be treated as a connection error (Section 5.4.1 of
<xref target="RFC7540"></xref>) of type PROTOCOL_ERROR.</t>

</section>
<section anchor="security" title="Security Considerations">

<t>The TLS extended master secret extension <xref target="RFC7627"></xref> and the TLS renegotiation
indication extension <xref target="RFC5746"></xref> MUST be used to mitigate several known attacks on
TLS renegotiation.</t>

<t>Adding correlation between requests and TLS-layer authentication addresses the
primary functional concerns with mid-session client authentication.  However,
implementations need to be aware of the potential for confusion about the state
of a connection.</t>

<t>The presence or absence of a validated client certificate can change during the
processing of a request, potentially multiple times.  A server that uses
reactive certificate authentication needs to be prepared to reevaluate the
authorization state of a request as the set of certificates changes.</t>

</section>
<section anchor="iana" title="IANA Considerations">

<t>The TLS <spanx style="verb">application_context_id</spanx> extension is registered in <xref target="iana-extension"/>.
The HTTP/2 <spanx style="verb">SETTINGS_REACTIVE_AUTH</spanx> setting is registered in <xref target="iana-setting"/>.
The HTTP/2 <spanx style="verb">WAITING_FOR_AUTH</spanx> frame type is registered in <xref target="iana-frame"/>.</t>

<section anchor="iana-extension" title="TLS application_context_id Extension">

<t>The <spanx style="verb">application_context_id</spanx> TLS extension is registered in the “ExtensionType
Values” registry established by <xref target="RFC5246"></xref>.</t>

<t><list style="hanging">
  <t hangText='Value:'>
  EXTENSION-TBD</t>
  <t hangText='Extension name:'>
  application_context_id</t>
  <t hangText='Reference:'>
  This document.</t>
</list></t>

</section>
<section anchor="iana-setting" title="HTTP/2 SETTINGS_REACTIVE_AUTH Setting">

<t>The SETTINGS_REACTIVE_AUTH setting is registered in the “HTTP/2 Settings”
registry established in <xref target="RFC7540"></xref>.</t>

<t><list style="hanging">
  <t hangText='Name:'>
  SETTINGS_REACTIVE_AUTH</t>
  <t hangText='Code:'>
  0xSETTING-TBD</t>
  <t hangText='Initial Value:'>
  0</t>
  <t hangText='Specification:'>
  This document.</t>
</list></t>

</section>
<section anchor="iana-frame" title="HTTP/2 WAITING_FOR_AUTH Frame">

<t>The WAITING_FOR_AUTH frame type is registered in the “HTTP/2 Frame Types”
registry established in <xref target="RFC7540"></xref>.</t>

<t><list style="hanging">
  <t hangText='Frame Type:'>
  WAITING_FOR_AUTH</t>
  <t hangText='Code:'>
  0xFRAME-TBD</t>
  <t hangText='Specification:'>
  This document.</t>
</list></t>

</section>
</section>
<section anchor="ack" title="Acknowledgements">

<t>Eric Rescorla pointed out several failings in an earlier revision.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor='RFC2119' target='http://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor='RFC5246' target='http://www.rfc-editor.org/info/rfc5246'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'><organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2008' month='August' />
<abstract><t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol.  The TLS protocol provides communications security over the Internet.  The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5246'/>
<seriesInfo name='DOI' value='10.17487/RFC5246'/>
</reference>



<reference  anchor='RFC5746' target='http://www.rfc-editor.org/info/rfc5746'>
<front>
<title>Transport Layer Security (TLS) Renegotiation Indication Extension</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<author initials='M.' surname='Ray' fullname='M. Ray'><organization /></author>
<author initials='S.' surname='Dispensa' fullname='S. Dispensa'><organization /></author>
<author initials='N.' surname='Oskov' fullname='N. Oskov'><organization /></author>
<date year='2010' month='February' />
<abstract><t>Secure Socket Layer (SSL) and Transport Layer Security (TLS) renegotiation are vulnerable to an attack in which the attacker forms a TLS connection with the target server, injects content of his choice, and then splices in a new TLS connection from a client.  The server treats the client's initial TLS handshake as a renegotiation and thus believes that the initial data transmitted by the attacker is from the same entity as the subsequent client data.  This specification defines a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5746'/>
<seriesInfo name='DOI' value='10.17487/RFC5746'/>
</reference>



<reference  anchor='RFC7230' target='http://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor='RFC7301' target='http://www.rfc-editor.org/info/rfc7301'>
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
<author initials='S.' surname='Friedl' fullname='S. Friedl'><organization /></author>
<author initials='A.' surname='Popov' fullname='A. Popov'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2014' month='July' />
<abstract><t>This document describes a Transport Layer Security (TLS) extension for application-layer protocol negotiation within the TLS handshake. For instances in which multiple application protocols are supported on the same TCP or UDP port, this extension allows the application layer to negotiate which protocol will be used within the TLS connection.</t></abstract>
</front>
<seriesInfo name='RFC' value='7301'/>
<seriesInfo name='DOI' value='10.17487/RFC7301'/>
</reference>



<reference  anchor='RFC7540' target='http://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2).  HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection.  It also introduces unsolicited push of representations from servers to clients.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference  anchor='RFC7627' target='http://www.rfc-editor.org/info/rfc7627'>
<front>
<title>Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension</title>
<author initials='K.' surname='Bhargavan' fullname='K. Bhargavan' role='editor'><organization /></author>
<author initials='A.' surname='Delignat-Lavaud' fullname='A. Delignat-Lavaud'><organization /></author>
<author initials='A.' surname='Pironti' fullname='A. Pironti'><organization /></author>
<author initials='A.' surname='Langley' fullname='A. Langley'><organization /></author>
<author initials='M.' surname='Ray' fullname='M. Ray'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the server certificate.  Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same.  Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server.  This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks.</t></abstract>
</front>
<seriesInfo name='RFC' value='7627'/>
<seriesInfo name='DOI' value='10.17487/RFC7627'/>
</reference>



<reference anchor='I-D.ietf-tls-tls13'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='August' day='28' year='2015' />

<abstract><t>This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol.  The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-08.txt' />
</reference>




    </references>




  </back>
</rfc>