One document matched: draft-thomson-webpush-vapid-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-webpush-vapid-00" category="std">

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

  <front>
    <title abbrev="Self Identification">Voluntary Application Server Identification for Web Push</title>

    <author initials="M." surname="Thomson" fullname="Martin Thomson">
      <organization>Mozilla</organization>
      <address>
        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date year="2015"/>

    
    
    

    <abstract>


<t>An application server can voluntarily identify itself to a push service using
the described technique.  This identification information can be used by the
push service to attribute requests that are made by the same application server
to a single entity.  An application server is further able include additional
information the operator of a push service can use to contact the operator of
the application server.</t>



    </abstract>


  </front>

  <middle>


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

<t>The Web Push protocol <xref target="I-D.ietf-webpush-protocol"></xref> describes how an application
server is able to request that a push service deliver a push message to a user
agent.</t>

<t>As a consequence of the expected deployment architecture, there is no basis for
an application server to be known to a push service prior to requesting delivery
of a push message.  By the same measure, requesting the creation of a
subscription for push message receipts has no prior authentication.  Requiring
that the push service be able to authenticate application servers places an
unwanted constraint on the interactions between user agents and application
servers, who are the ultimate users of a push service.  That constraint would
also degrade the privacy-preserving properties the protocol provides.  For these
reasons, <xref target="I-D.ietf-webpush-protocol"></xref> does not define a mandatory system for
authentication of application servers.</t>

<t>An unfortunate consequence of this design is that a push service is exposed to a
greater risk of denial of service attack.  While requests from application
servers can be indirectly attributed to user agents, this is not always
efficient or even sufficient.  Providing more information about the application
server more directly to a push service allows the push service to better
distinguish between legitimate and bogus requests.</t>

<t>This document describes a system whereby an application server can volunteer
information about itself to a push service.  At a minimum, this provides a
stable identity for the application server, though this could also include
contact information, such as an email address.</t>

<t>A consistent identity can be used by a push service to establish behavioral
expectations for an application server.  Significant deviations from an
established norm can then be used to trigger exception handling procedures.</t>

<t>Voluntarily-provided contact information can be used to contact an application
server operator in the case of exceptional situations.</t>

<t>Experience with push service deployment has shown that software errors or
unusual circumstances can cause large increases in push message volume.
Contacting the operator of the application server has proven to be valuable.</t>

<t>Even in the absence of usable contact information, an application server that
has a well-established reputation might be given preference over an unidentified
application server when choosing whether to discard a push message.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>The words “MUST”, “MUST NOT”, “SHOULD”, and “MAY” are used in this document.
It’s not shouting, when they are capitalized, they have the special meaning
described in <xref target="RFC2119"></xref>.</t>

<t>The terms “push message”, “push service”, “application server”, and “user agent”
are used as defined in <xref target="I-D.ietf-webpush-protocol"></xref></t>

</section>
</section>
<section anchor="self-identification" title="Self-Identification">

<t>A push service that supports application server self-identification requests a
client certificate from application servers.  The client certificate is
requested during the TLS <xref target="RFC5246"></xref> handshake.</t>

<t>An application server that does not have a client certificate offers no
certificate in response; an application server that wishes to self-identify
includes a certificate.</t>

<t>The certificate that the application server offers SHOULD be self-signed (see
Section 3.2 of <xref target="RFC5280"></xref>).  The certificate MAY contain an alternative name
extension (Section 4.2.1.6 of <xref target="RFC5280"></xref>) that includes contact information.  Of
the available options, an email address using the <spanx style="verb">rfc822Name</spanx> form or an HTTP
<xref target="RFC7230"></xref> (or HTTPS <xref target="RFC2818"></xref>) <spanx style="verb">uniformResourceIdentifier</spanx> SHOULD be included,
though including other options are not prohibited.</t>

<t>The offered end-entity certificate or the public key it contains becomes an
identifier for the application server.  Push services are able to reduce the
data they retain for an application server, either by extracting important
information like the subject public key information (SPKI), by hashing, or a
combination.  Of course, a push service might choose to ignore the provided
information.</t>

<t>To avoid requesting certificates from user agents, it might be necessary to
serve requests from user agents and requests from application servers on
different hostnames or port numbers.</t>

<section anchor="alternatives" title="Alternatives">

<t>Several options have been proposed, here are some of the more concrete options.
Some options might even be better than the certificate-based option.</t>

<section anchor="token" title="Application Tokens">

<t>In this model, the push service vends a token to each application server that
requests it.  That token is kept secret and used as the basis for
authentication.</t>

<t>This doesn’t address the need for contact information, but it addresses the need
for a consistent application server identifier.</t>

<t>A Cookie <xref target="RFC6265"></xref> is a token of this nature.  All the considerations regarding
the use (and misuse) of HTTP cookies apply should this option be chosen.  A
mechanism that makes token theft more difficult, such as
<xref target="I-D.ietf-tokbind-https"></xref> might be needed.  However that suggests a separate
option (see <xref target="tokbind"/>).</t>

<t>This information would be repeated with each request, but that overhead is
greatly reduced by header compression <xref target="RFC7541"></xref> in HTTP/2 <xref target="RFC7540"></xref>.</t>

</section>
<section anchor="contact-information-header-field" title="Contact Information Header Field">

<t>Contact information for an application server could be included in a header
field, either directly (e.g., a From header field, Section 5.5.1 of <xref target="RFC7231"></xref>),
or by reference (e.g., a new “contact” link relation <xref target="RFC5988"></xref> that identified a
vCard <xref target="RFC6350"></xref>).  Note that a From header field is limited to email addresses.</t>

<t>Like an application token <xref target="token"/>, contact information would need to be
repeated, though that cost is reduced with HTTP/2.</t>

</section>
<section anchor="request-signing" title="Request Signing">

<t>Signing of push message requests would allow the push service to attribute
requests to an application server based on an asymmetric key.  This could be
done in any number of ways JWS <xref target="RFC7515"></xref> and HTTP signatures
<xref target="I-D.cavage-http-signatures"></xref> being the most likely options.  Note that the
latter does not provide a means of conveying the signing key, which would be
necessary for this application.</t>

<t>Request signing has several limitations:</t>

<t><list style="symbols">
  <t>Deciding what to sign is challenging.  Signing only the body of a message is
not sufficient to prevent message replay attacks.</t>
  <t>Every message contains a signature, which can increase the load on a server
signficantly.  This is especially bad if a signature validation result is
input to denial of service mitigation decision making.</t>
</list></t>

</section>
<section anchor="tokbind" title="Token Binding">

<t>The mechanism proposed in <xref target="I-D.ietf-tokbind-https"></xref> can be used to provide a
stable identifier for application servers.  This includes a signature over
material that is exported from the underlying TLS connection.  Importantly, this
does not require a new signature for each request: the same signature is
repeated for every request, HTTP/2 is again used to reduce the cost of the
repeated information.</t>

<t>Token binding could be used independently of cookies.  Consequently, an
application server would not be required to accept and store cookies, though the
push service would not be able to offload any state as a result.</t>

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

<t>This document has no IANA actions (yet).</t>

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

<t>TLS 1.2 <xref target="RFC5246"></xref> does not provide any confidentiality protections for client
certificates.  A network attacker can therefore see the identification
information that is provided by the application server.  A push service MAY
choose to offer confidentiality protection for application server identity by
initiating TLS renegotiation immediately after establishing the TLS connection
at the cost of some additional latency.  Using TLS 1.3 <xref target="I-D.ietf-tls-tls13"></xref>
provides confidentiality protection for this information without additional
latency.</t>

<t>An application server might offer falsified contact information.  A push service
operator therefore cannot use the presence of unvalidated contact information as
input to any security-critical decision-making process.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference anchor='I-D.ietf-webpush-protocol'>
<front>
<title>Generic Event Delivery Using HTTP Push</title>

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

<author initials='E' surname='Damaggio' fullname='Elio Damaggio'>
    <organization />
</author>

<author initials='B' surname='Raymor' fullname='Brian Raymor'>
    <organization />
</author>

<date month='October' day='15' year='2015' />

<abstract><t>A simple protocol for the delivery of realtime events to user agents is described.  This scheme uses HTTP/2 server push.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-webpush-protocol-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-webpush-protocol-01.txt' />
<format type='PDF'
        target='http://www.ietf.org/internet-drafts/draft-ietf-webpush-protocol-01.pdf' />
</reference>



<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='RFC5280' target='http://www.rfc-editor.org/info/rfc5280'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'><organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'><organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'><organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'><organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'><organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'><organization /></author>
<date year='2008' month='May' />
<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5280'/>
<seriesInfo name='DOI' value='10.17487/RFC5280'/>
</reference>



<reference  anchor='RFC2818' target='http://www.rfc-editor.org/info/rfc2818'>
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'><organization /></author>
<date year='2000' month='May' />
<abstract><t>This memo describes how to use Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t></abstract>
</front>
<seriesInfo name='RFC' value='2818'/>
<seriesInfo name='DOI' value='10.17487/RFC2818'/>
</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>




    </references>

    <references title='Informative References'>





<reference  anchor='RFC7231' target='http://www.rfc-editor.org/info/rfc7231'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</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 defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t></abstract>
</front>
<seriesInfo name='RFC' value='7231'/>
<seriesInfo name='DOI' value='10.17487/RFC7231'/>
</reference>



<reference  anchor='RFC7515' target='http://www.rfc-editor.org/info/rfc7515'>
<front>
<title>JSON Web Signature (JWS)</title>
<author initials='M.' surname='Jones' fullname='M. Jones'><organization /></author>
<author initials='J.' surname='Bradley' fullname='J. Bradley'><organization /></author>
<author initials='N.' surname='Sakimura' fullname='N. Sakimura'><organization /></author>
<date year='2015' month='May' />
<abstract><t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures.  Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification.  Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t></abstract>
</front>
<seriesInfo name='RFC' value='7515'/>
<seriesInfo name='DOI' value='10.17487/RFC7515'/>
</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='RFC7541' target='http://www.rfc-editor.org/info/rfc7541'>
<front>
<title>HPACK: Header Compression for HTTP/2</title>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='H.' surname='Ruellan' fullname='H. Ruellan'><organization /></author>
<date year='2015' month='May' />
<abstract><t>This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.</t></abstract>
</front>
<seriesInfo name='RFC' value='7541'/>
<seriesInfo name='DOI' value='10.17487/RFC7541'/>
</reference>



<reference  anchor='RFC6350' target='http://www.rfc-editor.org/info/rfc6350'>
<front>
<title>vCard Format Specification</title>
<author initials='S.' surname='Perreault' fullname='S. Perreault'><organization /></author>
<date year='2011' month='August' />
<abstract><t>This document defines the vCard data format for representing and exchanging a variety of information about individuals and other entities (e.g., formatted and structured name and delivery addresses, email address, multiple telephone numbers, photograph, logo, audio clips, etc.).  This document obsoletes RFCs 2425, 2426, and 4770, and updates RFC 2739.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6350'/>
<seriesInfo name='DOI' value='10.17487/RFC6350'/>
</reference>



<reference  anchor='RFC5988' target='http://www.rfc-editor.org/info/rfc5988'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2010' month='October' />
<abstract><t>This document specifies relation types for Web links, and defines a registry for them.  It also defines the use of such links in HTTP headers with the Link header field.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5988'/>
<seriesInfo name='DOI' value='10.17487/RFC5988'/>
</reference>



<reference  anchor='RFC6265' target='http://www.rfc-editor.org/info/rfc6265'>
<front>
<title>HTTP State Management Mechanism</title>
<author initials='A.' surname='Barth' fullname='A. Barth'><organization /></author>
<date year='2011' month='April' />
<abstract><t>This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol.  Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.  This document obsoletes RFC 2965.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6265'/>
<seriesInfo name='DOI' value='10.17487/RFC6265'/>
</reference>



<reference anchor='I-D.cavage-http-signatures'>
<front>
<title>Signing HTTP Messages</title>

<author initials='M' surname='Cavage' fullname='Mark Cavage'>
    <organization />
</author>

<author initials='M' surname='Sporny' fullname='Manu Sporny'>
    <organization />
</author>

<date month='October' day='7' year='2015' />

<abstract><t>When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message.  It can also be desirable to ensure that the message was not tampered with during transit.  This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-cavage-http-signatures-05' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-cavage-http-signatures-05.txt' />
</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='October' day='19' 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-10' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-10.txt' />
</reference>



<reference anchor='I-D.ietf-tokbind-https'>
<front>
<title>Token Binding over HTTP</title>

<author initials='A' surname='Popov' fullname='Andrey Popov'>
    <organization />
</author>

<author initials='M' surname='Nystrom' fullname='Magnus Nystrom'>
    <organization />
</author>

<author initials='D' surname='Balfanz' fullname='Dirk Balfanz'>
    <organization />
</author>

<author initials='A' surname='Langley' fullname='Adam Langley'>
    <organization />
</author>

<date month='October' day='15' year='2015' />

<abstract><t>This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to a TLS [RFC5246] connection.  We describe both _first-party_ as well as _federated_ scenarios.  In a first-party scenario, an HTTP server issues a security token (such as a cookie) to a client, and expects the client to send the security token back to the server at a later time in order to authenticate. Binding the token to the TLS connection between client and server protects the security token from theft, and ensures that the security token can only be used by the client that it was issued to.  Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS [RFC5246] connection that the client has with a _different_ server than the one issuing the token.  This Internet-Draft is a companion document to The Token Binding Protocol [TBPROTO]</t></abstract>

</front>

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




    </references>



  </back>
</rfc>