[Webpush] Application server authentication new years edition

Martin Thomson <martin.thomson@gmail.com> Wed, 06 January 2016 03:35 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: webpush@ietfa.amsl.com
Delivered-To: webpush@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591C1A8BB5 for <webpush@ietfa.amsl.com>; Tue, 5 Jan 2016 19:35:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWTdYPigeZED for <webpush@ietfa.amsl.com>; Tue, 5 Jan 2016 19:35:31 -0800 (PST)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6791A8BB2 for <webpush@ietf.org>; Tue, 5 Jan 2016 19:35:31 -0800 (PST)
Received: by mail-ig0-x231.google.com with SMTP id to18so24928924igc.0 for <webpush@ietf.org>; Tue, 05 Jan 2016 19:35:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=/nb7OKcfNpBhCGfyRmTqob9gzYMg54l2TexdzYb9FF4=; b=hLmuUJaPqBEbDoDD/3qav5clE5OSiE7mOlcnq+SI4rD5DvnbPdhK/eotqtwotWcntL kKulSn2SRIQTqWaKmliLeHt2JHOqJZeJ11tLuLbs3Ws6EKIQueSUS9UsCWzRmUxF1k9F 6hTHuIWMBL09CLHut/gJxAKxLyyHvwqWqsCekZroOQADyxhHOyMsytwOSV8cnrM7kThj mKiR7BRCfYZ91dT8rrXWUymFNXjtDhx+H/6Vrh1ksa+QBFpAycGssPT4PaHXxsuajuV5 omRfSS1iI78wCLj/aV7PSWs9jXl9gphi7hI5PePUrdVRvu0ysXGuRT1TzOK1e5AHdWqt X+7w==
MIME-Version: 1.0
X-Received: by 10.50.66.179 with SMTP id g19mr7469047igt.94.1452051331124; Tue, 05 Jan 2016 19:35:31 -0800 (PST)
Received: by 10.36.149.130 with HTTP; Tue, 5 Jan 2016 19:35:31 -0800 (PST)
Date: Wed, 6 Jan 2016 14:35:31 +1100
Message-ID: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "webpush@ietf.org" <webpush@ietf.org>, Ben Bangert <bbangert@mozilla.com>, Costin Manolache <costin@google.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/8NQbry30HT25LGCctq4N3phU6Rc>
Subject: [Webpush] Application server authentication new years edition
X-BeenThere: webpush@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of potential IETF work on a web push protocol <webpush.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/webpush>, <mailto:webpush-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/webpush/>
List-Post: <mailto:webpush@ietf.org>
List-Help: <mailto:webpush-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/webpush>, <mailto:webpush-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2016 03:35:33 -0000

With Peter's help, I've just submitted a new version of a draft that
attempts to enumerate the options for application server
authentication (issue #44).

  https://tools.ietf.org/html/draft-thomson-webpush-vapid-01

This assumes the following requirements:

1. A push service would like to be able to correlate requests from a
particular application server over time.

2. A push service would like to be able to contact the
operator/developer of an application server.

This takes the position that any correlation or contact information is
provided voluntarily by an application server and that we don't
require strong authentication for application servers.

Both Ben and Costin have suggested that we could (SHOULD?) construct a
scheme to strongly authenticate servers.  Ben observed that most web
push consumers will have HTTPS endpoints with valid server
certificates and we could use that to construct a system that strongly
authenticates senders.  That might be possible, but it's likely to be
a complicated system that introduces a whole new set of technical,
operational and privacy problems.

The voluntary authentication incrementally improves the situation and
allows us to build stronger authentication systems on top in future.
I think that we should look at doing that, but I would be opposed to
anything that made a more heavyweight authentication system mandatory
to use.

So I come to the question:  what levels of authentication do we want
to support for application servers?

  A. anonymous/none - push without being authenticated

  B. voluntary authentication - as proposed in the draft

  C. strong - proposal TBD