[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-webpush-vapid

Network Working Group                                         M. Thomson
Internet-Draft                                                   Mozilla
Intended status: Standards Track                             P. Beverloo
Expires: July 8, 2016                                             Google
                                                         January 5, 2016


        Voluntary Application Server Identification for Web Push
                     draft-thomson-webpush-vapid-01

Abstract

   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, and
   reduce the need for endpoint secrecy by being able to associate
   subscriptions with an application server.  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.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 8, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect



Thomson & Beverloo        Expires July 8, 2016                  [Page 1]


Internet-Draft             Self Identification              January 2016


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Self-Identification Alternatives  . . . . . . . . . . . . . .   4
     2.1.  Certificates  . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Server-Vended Tokens  . . . . . . . . . . . . . . . . . .   4
     2.3.  Client-Vended Tokens  . . . . . . . . . . . . . . . . . .   5
     2.4.  Contact Information Header Field  . . . . . . . . . . . .   6
     2.5.  Request Signing . . . . . . . . . . . . . . . . . . . . .   6
     2.6.  Token Binding . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Subscription Association  . . . . . . . . . . . . . . . . . .   7
     3.1.  Amendments to Subscribing for Push Messages . . . . . . .   7
     3.2.  Amendments to Requesting Push Message Delivery  . . . . .   7
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Web Push protocol [I-D.ietf-webpush-protocol] describes how an
   application server is able to request that a push service deliver a
   push message to a user agent.

   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, [I-D.ietf-webpush-protocol] does not define a
   mandatory system for authentication of application servers.

   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



Thomson & Beverloo        Expires July 8, 2016                  [Page 2]


Internet-Draft             Self Identification              January 2016


   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.

   Additionally, this design also relies on endpoint secrecy as any
   application server in possession of the endpoint is able to send
   messages, albeit without payloads.  In situations where usage of a
   subscription can be limited to a single application server, the
   ability to associate said subscription with the application server
   provides could reduce the impact of a data leak.

   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.

   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.

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

   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.

   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.

1.1.  Notational Conventions

   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 [RFC2119].

   The terms "push message", "push service", "application server", and
   "user agent" are used as defined in [I-D.ietf-webpush-protocol]







Thomson & Beverloo        Expires July 8, 2016                  [Page 3]


Internet-Draft             Self Identification              January 2016


2.  Self-Identification Alternatives

   Several options have been proposed, here are some of the more
   concrete options.

2.1.  Certificates

   A push service that supports application server self-identification
   requests a client certificate from application servers.  The client
   certificate is requested during the TLS [RFC5246] handshake.

   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.

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

   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.

   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.

2.2.  Server-Vended Tokens

   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.

   This doesn't address the need for contact information, but it
   addresses the need for a consistent application server identifier.

   A Cookie [RFC6265] 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 [I-D.ietf-tokbind-https] might be needed.  However that
   suggests a separate option (see Section 2.6).



Thomson & Beverloo        Expires July 8, 2016                  [Page 4]


Internet-Draft             Self Identification              January 2016


   This information would be repeated with each request, but that
   overhead is greatly reduced by header compression [RFC7541] in HTTP/2
   [RFC7540].

2.3.  Client-Vended Tokens

   In this model, clients generates a token that it uses to prove
   ownership over a private key.  Use of the same key over time
   establishes a continuous identity.

   Push message requests can be accompanied by a JSON Web Token (JWT)
   [RFC7519].  An "aud" (Audience) claim in the token MUST include the
   push resource URL.  This binds the token to a specific push
   subscription, but not a specific push message.  As a result, the
   token is reusable, limited by the value of the "exp" (Expiry) claim
   in the token.  An "exp" claim MUST be included.

   The JWT is included in an Authorization header field, using an auth-
   scheme of "WebPush".

   Editor's Note:  The definition of the "Bearer" auth-scheme in
      [RFC6750] is almost perfect, but context would seem to indicate
      that this is only valid for use with OAuth.

   The corresponding public key is included in a JSON Web Key (JWK)
   [RFC7517].  This would be included in either a newly-defined "jwk"
   parameter of the Crypto-Key header field
   [I-D.ietf-httpbis-encryption-encoding]; alternatively, the
   "p256ecdsa" parameter defined in [I-D.thomson-http-content-signature]
   could be used to transport a raw key.

   For voluntarily-provided contact details, a separate header field
   could be used (as in Section 2.4) or the JWT could include claims
   about identity.  For the latter, the "sub" (subject) claim could
   include a contact URI for the application server.

   The JWT MUST use a JSON Web Signature (JWS) [RFC7515].  Both the JWS
   and JWK MUST use an elliptic curve digital signature (ECDSA) key on
   the NIST P-256 curve [FIPS186].

   A JWT also offers the option of including contact information as an
   additional claim.  An "iss" (Issuer) claim can include a contact URI:
   either a "mailto:" (email) [RFC6068] or an "https:" [RFC2818] SHOULD
   be used.







Thomson & Beverloo        Expires July 8, 2016                  [Page 5]


Internet-Draft             Self Identification              January 2016


2.4.  Contact Information Header Field

   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 [RFC7231]), or by reference (e.g., a new "contact"
   link relation [RFC5988] that identified a vCard [RFC6350]).  Note
   that a From header field is limited to email addresses.

   Like an server- or client-vended token (Section 2.2, Section 2.3),
   contact information would need to be repeated, though that cost is
   reduced with HTTP/2.

2.5.  Request Signing

   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 [RFC7515] and HTTP
   signatures [I-D.cavage-http-signatures] 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.

   Request signing shares much in common with client-vended tokens
   Section 2.3, but it removes any possibility of token reuse in the
   interests of security.

   Request signing has a few shortcomings:

   o  Deciding what to sign is challenging.  Signing only the body of a
      message is not sufficient to prevent message replay attacks.

   o  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.

2.6.  Token Binding

   The mechanism proposed in [I-D.ietf-tokbind-https] 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.

   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.



Thomson & Beverloo        Expires July 8, 2016                  [Page 6]


Internet-Draft             Self Identification              January 2016


3.  Subscription Association

   A stable identifier for an application server - such as a public key
   or a token - could also be used to associate a subscription with the
   application server.

   Subscription association reduces the reliance on endpoint secrecy by
   requiring proof of possession to be demonstrated by an application
   server when requesting delivery of a push message.  This provides an
   additional level of protection against leaking of the details of the
   push subscription.

3.1.  Amendments to Subscribing for Push Messages

   The user agent includes the public key or token of the application
   server when requesting the creation of a subscription.  For example,
   the Web Push API [API] could allow an application to provide a public
   key as part of a new field on the "PushSubscriptionOptions"
   dictionary.

   This token might then be added to the request to create a push
   subscription.

   Allowing the inclusion of multiple keys when creating a subscription
   would allow a subscription to be associated with multiple application
   servers or application server instances.  This would require more
   state to be maintained by the push service for each subscription.

3.2.  Amendments to Requesting Push Message Delivery

   When a subscription has been associated with an application server,
   the request for push message delivery MUST include proof of
   possession for the associated private key or token that was used when
   creating the subscription.  Requests that do not contain proof of
   possession are rejected with a 401 (Unauthorized) status code.

4.  IANA Considerations

   This document has no IANA actions (yet).

5.  Security Considerations

   TLS 1.2 [RFC5246] 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



Thomson & Beverloo        Expires July 8, 2016                  [Page 7]


Internet-Draft             Self Identification              January 2016


   the cost of some additional latency.  Using TLS 1.3
   [I-D.ietf-tls-tls13] provides confidentiality protection for this
   information without additional latency.

   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.

   Many of the alternative solutions are vulnerable to replay attacks.
   Applying narrow limits to the period over which a replayable token
   can be reused limits the potential value of a stolen token to an
   attacker and can increase the difficulty of stealing a token.  The
   token binding solution, which binds tokens to a single TLS connection
   can make tokens less reusable.

6.  Acknowledgements

   This document would have been much worse than it currently is if not
   for the contributions of Benjamin Bangert, Chris Karlof, Costin
   Manolache, and others.

7.  References

7.1.  Normative References

   [FIPS186]  National Institute of Standards and Technology (NIST),
              "Digital Signature Standard (DSS)", NIST PUB 186-4 , July
              2013.

   [I-D.ietf-webpush-protocol]
              Thomson, M., Damaggio, E., and B. Raymor, "Generic Event
              Delivery Using HTTP Push", draft-ietf-webpush-protocol-02
              (work in progress), November 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,
              <http://www.rfc-editor.org/info/rfc5246>.



Thomson & Beverloo        Expires July 8, 2016                  [Page 8]


Internet-Draft             Self Identification              January 2016


   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.

   [RFC6068]  Duerst, M., Masinter, L., and J. Zawinski, "The 'mailto'
              URI Scheme", RFC 6068, DOI 10.17487/RFC6068, October 2010,
              <http://www.rfc-editor.org/info/rfc6068>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

7.2.  Informative References

   [API]      van Ouwerkerk, M. and M. Thomson, "Web Push API", 2015,
              <https://w3c.github.io/push-api/>.

   [I-D.cavage-http-signatures]
              Cavage, M. and M. Sporny, "Signing HTTP Messages", draft-
              cavage-http-signatures-05 (work in progress), October
              2015.

   [I-D.ietf-httpbis-encryption-encoding]
              Thomson, M., "Encrypted Content-Encoding for HTTP", draft-
              ietf-httpbis-encryption-encoding-00 (work in progress),
              December 2015.

   [I-D.ietf-tls-tls13]
              Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", draft-ietf-tls-tls13-11 (work in progress),
              December 2015.

   [I-D.ietf-tokbind-https]
              Popov, A., Nystrom, M., Balfanz, D., and A. Langley,
              "Token Binding over HTTP", draft-ietf-tokbind-https-02
              (work in progress), October 2015.

   [I-D.thomson-http-content-signature]
              Thomson, M., "Content-Signature Header Field for HTTP",
              draft-thomson-http-content-signature-00 (work in
              progress), July 2015.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988,
              DOI 10.17487/RFC5988, October 2010,
              <http://www.rfc-editor.org/info/rfc5988>.



Thomson & Beverloo        Expires July 8, 2016                  [Page 9]


Internet-Draft             Self Identification              January 2016


   [RFC6265]  Barth, A., "HTTP State Management Mechanism", RFC 6265,
              DOI 10.17487/RFC6265, April 2011,
              <http://www.rfc-editor.org/info/rfc6265>.

   [RFC6350]  Perreault, S., "vCard Format Specification", RFC 6350,
              DOI 10.17487/RFC6350, August 2011,
              <http://www.rfc-editor.org/info/rfc6350>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <http://www.rfc-editor.org/info/rfc6750>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <http://www.rfc-editor.org/info/rfc7515>.

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <http://www.rfc-editor.org/info/rfc7519>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <http://www.rfc-editor.org/info/rfc7540>.

   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
              <http://www.rfc-editor.org/info/rfc7541>.

Authors' Addresses

   Martin Thomson
   Mozilla

   Email: martin.thomson@gmail.com






Thomson & Beverloo        Expires July 8, 2016                 [Page 10]


Internet-Draft             Self Identification              January 2016


   Peter Beverloo
   Google

   Email: beverloo@google.com















































Thomson & Beverloo        Expires July 8, 2016                 [Page 11]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/