One document matched: draft-bishop-httpbis-http2-additional-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.30 -->

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

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

<rfc ipr="trust200902" docName="draft-bishop-httpbis-http2-additional-certs-00" category="std">

  <front>
    <title abbrev="HTTP/2 Additional Certs">Secondary Server-Certificate Authentication in HTTP/2</title>

    <author initials="M." surname="Bishop" fullname="Mike Bishop">
      <organization>Microsoft</organization>
      <address>
        <email>michael.bishop@microsoft.com</email>
      </address>
    </author>

    <date year="2016"/>

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

    <abstract>


<t>Many HTTP servers host content from several origins. HTTP/2 <xref target="RFC7540"></xref> 
permits clients to reuse an existing HTTP connection to a server 
provided that certain conditions are satisfied. One of these conditions 
is the inclusion of the secondary origin in the certificate provided 
during the TLS <xref target="I-D.ietf-tls-tls13"></xref> handshake.</t>

<t>In many cases, origins will wish to maintain separate certificates for 
different origins but still desire the benefits of a shared HTTP 
connection. This draft describes how frames which were defined to 
transfer client certificates might be used to provide additional server 
certificates as well.</t>



    </abstract>


  </front>

  <middle>


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

<t>Section 9.1.1 of <xref target="RFC7540"></xref> describes how connections may be reused as 
long as the server is authoritative for both origins. A server is 
considered authoritative for both origins if DNS resolves both origins 
to the IP address of the server and (for TLS) if the certificate 
presented by the server contains both origins, either as the Subject
or contained in the Subject Alternative Names field.</t>

<t><xref target="I-D.ietf-httpbis-alt-svc"></xref> enables a step of abstraction from the DNS 
resolution. If both hosts have provided an Alternative Service at 
hostnames which resolve to the IP address of the server, they are 
considered authoritative just as if DNS resolved the origin itself to 
that address.</t>

<t>The ORIGIN extension frame, defined in 
<xref target="I-D.nottingham-httpbis-origin-frame"></xref>, provides a negative coalescing 
feature – a way for a server to request that a client <spanx style="emph">not</spanx> reuse a 
connection for an origin, even when it might otherwise appear to be 
supported. However, the ORIGIN frame does not currently permit a server 
to advertise the availability of origins which do not appear in the 
server’s certificate as presented in the TLS handshake.</t>

<t>Servers which host many origins often would prefer to have separate 
certificates for some sets of origins. This may be for ease of 
certificate management (the ability to separately revoke or renew them), 
for legal reasons (a CDN acting on behalf of multiple origins), or any 
other factor which might drive this administrative decision. Clients 
connecting to such origins cannot currently reuse connections, even if 
both client and server would be willing to do so.</t>

<t><xref target="I-D.thomson-http2-client-certs"></xref> defines certificate-related HTTP/2 
frames, permitting a sender to offer a certificate chain along with 
proof that it possesses the corresponding private key to the end 
certificate. These frames are bound to the underlying TLS session, so 
that the certificates are as reliable as those provided at the TLS 
layer.</t>

<t>In this document, a mechanism for using these frames for secondary 
server authentication via HTTP/2 frames is defined. This mechanism can 
be implemented at the HTTP layer without requiring new TLS stack 
behavior and without breaking the existing interface between HTTP and 
applications above it. It primarily relaxes the one-way nature of the 
frames defined in <xref target="I-D.thomson-http2-client-certs"></xref>, defining the 
processing of these frames in the reverse direction.</t>

<section anchor="origin-discovery" title="Origin Discovery">

<section anchor="discovery-client" title="Client-driven discovery">

<t>As defined in <xref target="RFC7540"></xref>, when a client finds that a https:// origin (or 
Alternative Service <xref target="I-D.ietf-httpbis-alt-svc"></xref>) to which it needs to 
make a request has the same IP address as a server to which it is 
already connected, it MAY check whether the TLS certificate provided 
contains the new origin as well, and if so, reuse the connection.</t>

<t>If not, but the server has advertised support for HTTP-layer 
certificates, the client MAY also send a <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame 
<xref target="http-cert-request"/> on stream zero requesting a certificate for the 
desired origin. The server responds with a series of <spanx style="verb">CERTIFICATE</spanx> 
frames containing the relevant certificate chain, if it possesses such a 
certificate. If not, the server responds with an empty <spanx style="verb">CERTIFICATE</spanx> 
frame.</t>

</section>
<section anchor="server-driven-discovery" title="Server-driven discovery">

<t>Because the approach in <xref target="discovery-client"/> requires an extra 
round-trip to the server before the client can determine whether a new 
TCP connection will be required, some origins will wish to proactively 
alert clients to certificates they possess. Servers might also wish to 
proactively prove their authority for an origin for which it intends to 
deliver pushed resources.</t>

<t>The server MAY send an <spanx style="verb">ORIGIN</spanx> frame including origins which are not in 
its TLS certificate. This represents an explicit claim by the server to 
possess the appropriate certificate – a claim the client MUST verify 
using the procedures in <xref target="discovery-client"/> before relying on the 
server’s authority for the claimed origin.</t>

<t>The server might push resources from an origin for which it is 
authoritative but for which the client has not received the certificate. 
In this case, the client SHOULD verify the server’s possession of an 
appropriate certificate by sending a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame on the 
pushed stream and a <spanx style="verb">CERTIFICATE_REQUEST</spanx> on stream zero. The client 
MUST NOT use the pushed resource until an appropriate certificate has 
been received and validated.</t>

</section>
</section>
</section>
<section anchor="presenting-server-certificates-at-the-http2-framing-layer" title="Presenting Server Certificates at the HTTP/2 Framing Layer">
<t>{#certs-http2}</t>

<t>When a client wishes to obtain additional certificates from a server 
that has signaled support for HTTP certificate authentication (see 
<xref target="setting"/>), it does this by sending at least one <spanx style="verb">CERTIFICATE_REQUEST</spanx> 
frame (see <xref target="http-cert-request"/>) on stream zero. A client MAY send 
multiple concurrent <spanx style="verb">CERTIFICATE_REQUEST</spanx> frames.  If server-initiated
streams are blocked until the <spanx style="verb">CERTIFICATE_REQUEST</spanx> has been answered,
the client SHOULD send <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frames on those streams
to inform the server.</t>

<t>Servers respond to certificate authentication requests by sending one or 
more <spanx style="verb">CERTIFICATE</spanx> frames (see <xref target="http-certificate"/>) followed by a 
<spanx style="verb">CERTIFICATE_PROOF</spanx> frame, on stream zero.</t>

<section anchor="http-cert-request" title="The CERTIFICATE_REQUEST Frame">

<t>When the server has advertised support for HTTP certificate 
authentication (see <xref target="setting"/>), clients MAY send the 
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame. A server that has advertised support MUST 
NOT treat receipt of such a frame as a session error of type 
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

<t>The <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame MUST be sent on stream zero. A 
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame received on any other stream MUST be 
rejected with a stream error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

<t>When sent from client to server, the <spanx style="verb">CERTIFICATE_REQUEST</spanx> frame has the 
same layout, with one change to the field definitions. The <spanx style="verb">CA-Count</spanx> 
and <spanx style="verb">Certificate-Authorities</spanx> fields are replaced by <spanx style="verb">Origin-Count</spanx> and 
<spanx style="verb">Origins</spanx> fields, with the same length and format. <spanx style="verb">Origins</spanx> is the 
distinguished name of the origin for which the client wishes to obtain a 
certificate, represented in DER-encoded <xref target="X690"></xref> format. The number of 
such structures is given by the 16-bit <spanx style="verb">Origin-Count</spanx> field, which MUST 
be one (0x01).</t>

</section>
<section anchor="http-cert-required" title="The CERTIFICATE_REQUIRED frame">

<t>The <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame is sent by clients to indicate that 
processing of a server-initiated stream (for example, a pushed resource) 
is blocked pending certificate authentication. The frame includes a 
request identifier which can be used to correlate the stream with a 
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frame received on stream zero. The layout and 
fields are unmodified from <xref target="I-D.thomson-http2-client-certs"></xref>.</t>

<t>When the server has advertised support for HTTP certificate 
authentication (see <xref target="setting"/>), clients MAY send the 
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame. A server that has advertised support MUST 
NOT treat receipt of such a frame as a stream error of type 
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

<t>The client MUST NOT send a <spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame on stream zero 
or a client-initiated stream. A server that receives a 
<spanx style="verb">CERTIFICATE_REQUIRED</spanx> frame on an inappropriate stream SHOULD treat 
this as a connection error of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

</section>
<section anchor="http-certificate" title="The CERTIFICATE frame">

<t>The <spanx style="verb">CERTIFICATE</spanx> frame allows the sender to present a certificate which 
should be used as authentication for previous or subsequent requests.</t>

<t>The payload of a <spanx style="verb">CERTIFICATE</spanx> frame contains elements of a certificate 
chain, terminating in an end certificate. The layout, fields, and 
processing are unmodified from <xref target="I-D.thomson-http2-client-certs"></xref>.</t>

</section>
<section anchor="http-cert-proof" title="The CERTIFICATE_PROOF Frame">

<t>The <spanx style="verb">CERTIFICATE_PROOF</spanx> frame allows the sender to prove possession of a 
certificate which should be used as authentication for previous or 
subsequent requests. The payload of a <spanx style="verb">CERTIFICATE_PROOF</spanx> frame contains 
proof of possession of the private key corresponding to an end 
certificate previously presented in a series of <spanx style="verb">CERTIFICATE</spanx> frames. 
The layout, fields, and processing are unmodified from 
<xref target="I-D.thomson-http2-client-certs"></xref>.</t>

<t>Servers MUST set the <spanx style="verb">AUTOMATIC_USE</spanx> flag when sending a 
<spanx style="verb">CERTIFICATE_PROOF</spanx> frame.</t>

</section>
<section anchor="http-use-certificate" title="The USE_CERTIFICATE Frame">

<t>The <spanx style="verb">USE_CERTIFICATE</spanx> frame is sent by servers to indicate that 
processing of a server-initiated stream should use a certificate 
provided in a previous series of <spanx style="verb">CERTIFICATE</spanx> and <spanx style="verb">CERTIFICATE_PROOF</spanx> 
frames. The frame includes a certificate identifier which can be used to 
correlate the stream with a certificate received on stream zero.</t>

<t>A <spanx style="verb">USE_CERTIFICATE</spanx> frame with no payload expresses the server’s choice 
to proceed without providing a certificate. Clients SHOULD process the 
request as authenticated solely by the certificate provided at the TLS 
layer, likely by discarding the pushed resource and terminating the 
stream.</t>

<t>Otherwise, the <spanx style="verb">USE_CERTIFICATE</spanx> frame contains a single octet, which is 
the authentication request identifier. A server that receives a 
<spanx style="verb">USE_CERTIFICATE</spanx> of any other length MUST treat this as a stream error 
of type <spanx style="verb">PROTOCOL_ERROR</spanx>. Frames with identical request identifiers 
refer to the same certificate chain.</t>

<t>The server MUST NOT send a <spanx style="verb">USE_CERTIFICATE</spanx> frame on stream zero or a 
client-initiated stream. A client that receives a <spanx style="verb">USE_CERTIFICATE</spanx> 
frame on an inappropriate stream SHOULD treat this as a connection error 
of type <spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

</section>
</section>
<section anchor="errors" title="Indicating failures during Certificate Authentication">

<t>The errors defined by <xref target="I-D.thomson-http2-client-certs"></xref> MAY be used by
either clients or servers, as appropriate.</t>

</section>
<section anchor="setting" title="Indicating Support for HTTP-Layer Certificate Authentication">

<t>Servers that support HTTP-layer certificate authentication indicate this 
using the HTTP/2 <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting defined in 
<xref target="I-D.thomson-http2-client-certs"></xref>.</t>

<t>The initial value for the <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting is 0, 
indicating that the server does not support HTTP-layer certificate 
authentication. A server sets the <spanx style="verb">SETTINGS_HTTP_CERT_AUTH</spanx> setting to a 
value of 1 to indicate support for HTTP-layer 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 
<spanx style="verb">PROTOCOL_ERROR</spanx>.</t>

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

<t>This mechanism defines an alternate way to obtain server certificates
other than the TLS handshake.  While the signature of exporter values
is expected to be equally secure, it is important to recognize that a
vulnerability in this code path is equal to a vulnerability in the TLS
handshake.</t>

<t>This draft defines a mechanism which could be used to probe servers for 
origins they support, but opens no new attack versus making repeat TLS 
connections with different SNI values. Servers SHOULD impose similar 
denial-of-service mitigations (e.g. request rate limits) to 
<spanx style="verb">CERTIFICATE_REQUEST</spanx> frames as to new TLS connections.</t>

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

<t>No changes are made to the registrations in 
<xref target="I-D.thomson-http2-client-certs"></xref>.</t>

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

</section>


  </middle>

  <back>

    <references title='Normative References'>





<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="X690" target="http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf">
  <front>
    <title>Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title>
    <author >
      <organization>ITU-T</organization>
    </author>
    <date year="2002"/>
  </front>
  <seriesInfo name="ISO" value="ISO/IEC 8825-1:2002"/>
</reference>




<reference anchor='I-D.thomson-http2-client-certs'>
<front>
<title>Reactive Certificate-Based Client Authentication in HTTP/2</title>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<author initials='M' surname='Bishop' fullname='Mike Bishop'>
    <organization />
</author>

<date month='January' day='22' year='2016' />

<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.  While TLS 1.3 provides an alternate mechanism to obtain client certificates, this mechanism does not map well to usage in TLS 1.2.  This document describes a how client authentication might be requested by a server as a result of receiving a request to a protected resource.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-thomson-http2-client-certs-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-thomson-http2-client-certs-01.txt' />
</reference>




    </references>

    <references title='Informative References'>





<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='December' 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-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-11.txt' />
</reference>



<reference anchor='I-D.nottingham-httpbis-origin-frame'>
<front>
<title>The ORIGIN HTTP/2 Frame</title>

<author initials='m' surname='mnot' fullname='mnot'>
    <organization />
</author>

<author initials='E' surname='Nygren' fullname='Erik Nygren'>
    <organization />
</author>

<date month='January' day='30' year='2016' />

<abstract><t>This document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-nottingham-httpbis-origin-frame-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-nottingham-httpbis-origin-frame-01.txt' />
</reference>



<reference anchor='I-D.ietf-httpbis-alt-svc'>
<front>
<title>HTTP Alternative Services</title>

<author initials='m' surname='mnot' fullname='mnot'>
    <organization />
</author>

<author initials='P' surname='McManus' fullname='Patrick McManus'>
    <organization />
</author>

<author initials='J' surname='Reschke' fullname='Julian Reschke'>
    <organization />
</author>

<date month='February' day='8' year='2016' />

<abstract><t>This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-alt-svc-12' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-alt-svc-12.txt' />
</reference>




    </references>




  </back>
</rfc>