Re: [Webpush] Application server authentication new years edition

Benjamin Bangert <bbangert@mozilla.com> Wed, 06 January 2016 22:24 UTC

Return-Path: <bbangert@mozilla.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 52EBF1A1ADC for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 14:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 hoD6XruQ9I6s for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 14:24:22 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 79DA41A1AE3 for <webpush@ietf.org>; Wed, 6 Jan 2016 14:24:22 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id n135so165580297qka.2 for <webpush@ietf.org>; Wed, 06 Jan 2016 14:24:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5y3zaXqBN7tCKxTWjnerOu3ikTyOFUhEbXJUOYBGUU4=; b=D6VwEdOTYIrTcyZeR14r5x+RPoiPVpklF5c2Jv1+ZMNf/v4XFgn+0GPmKNwfDH5UK7 nqiy9CyWF/+IlaqMO+Atpkc76om3h33vFPESEX4i+ihla+f3c8jQr6X7tuAvjb2nEdOQ 4HFYY9J1n0XIS7r4caTGNLzXvWamoqnzpdK1bS8EKU2sEoFPMLNvAEOpED+s3hqBEQY3 +2vEn22ssHHYJoDGuvCBKWki/+UlkdShLXYgISEA3kapNS+1Gpq6DFa1kzasC0RTrGKw jHy6vLUzCY+o79XwS63SSVy06JIKnRTu1DbQ+6sOmdGx76dB9GMw2ofg358MTB0/p5Cf 4M4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5y3zaXqBN7tCKxTWjnerOu3ikTyOFUhEbXJUOYBGUU4=; b=Tv+rH6hUokkxztFlQvV4IbJlo3p8zWVwb2iwbn3zUcAGBAmjtGG7l6SOOxtNVqKEA9 nSN1D5s3EF51W307PLUjmS2LYHs+6F2rQVpabHEEueinYoRStYkIVkKdUcCOQvGFAI/V yhBYjRTf0n4kyiZSX+wWh9U27E7F/HTi/EBSsOROiT6CT1GbdQUXDeU/OwaQU7A/uoIx xk9YS3ArBfR7G3EuR7EUvGodBTHkkOvaeScEgR/mo3vKUptGpnp2wnFNSprZJTYP4Qks D75ZalIbqKZriDgL33xG079alathLxNSa5Y+cipDZOYgxkpvrFWvasK6bU3MpYsXoxb4 OTkQ==
X-Gm-Message-State: ALoCoQnXo5h3xVQIX8Kkxiod1Dj2fIGVN2B0Uva4Qo0gLd48jf7I/OgyatzEPi3Zp7Fc7uFDapIhNQn2I1v502DhMjDVCciHJn8eJZUrFQ2xd19+8TG4nus=
MIME-Version: 1.0
X-Received: by 10.129.133.193 with SMTP id v184mr82161884ywf.262.1452119061405; Wed, 06 Jan 2016 14:24:21 -0800 (PST)
Received: by 10.37.224.9 with HTTP; Wed, 6 Jan 2016 14:24:21 -0800 (PST)
In-Reply-To: <CAP8-FqnnYtQrBbngna5a6PqfXxawq-ORh-HFA85tJ56VsNd=LA@mail.gmail.com>
References: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com> <CAP8-Fq=PhUcj5aaE6dvF2_+-HmVrGDyk41QBzkVxiNMxUakoag@mail.gmail.com> <CABkgnnUYkuu9pjuqLDhiWLNWzkr9ZfYRNny4ZvSKRTWie2bQyA@mail.gmail.com> <568D41D6.40904@mozilla.com> <CAP8-FqnnYtQrBbngna5a6PqfXxawq-ORh-HFA85tJ56VsNd=LA@mail.gmail.com>
Date: Wed, 6 Jan 2016 14:24:21 -0800
Message-ID: <CABp8EuLspfCA6+YfoSH_JOKi1To4EH4G22vkf_ZS3v397HtCJA@mail.gmail.com>
From: Benjamin Bangert <bbangert@mozilla.com>
To: Costin Manolache <costin@gmail.com>
Content-Type: multipart/alternative; boundary=001a114f02bed3d4b80528b1d039
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/W6M9dWKHhEYi5SEdCf1MWgSMGg0>
Cc: jr conlin <jconlin@mozilla.com>, "webpush@ietf.org" <webpush@ietf.org>
Subject: Re: [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 22:24:26 -0000

2.3 would allow us to get the data, but it doesn't address strongly
authenticate senders.

Discussing this earlier with my manager, there are two additional schemes
that we could consider instead of or in addition to 2.3 on a voluntary
basis for app-servers.

- DKIM: Re-use DKIM in some manner so that an app-server can claim a domain
its sending notifications on behalf of. Since DKIM also includes a body
hash, it could be used instead of JWT if an app-server wishes to strongly
authenticate.
- Lets Encrypt Domain Validation: The Lets Encrypt folks have a scheme and
tools that automate Domain Validation to prove ownership of a domain
(though it unfortunately needs to be tied into a webserver, DKIM is nicer
in that aspect of only requiring a DNS addition).

Both of these would allow an app-server to change the JWT secret being used
if needed with no interaction needed with the push service.

Cheers,
Ben

On Wed, Jan 6, 2016 at 11:29 AM, Costin Manolache <costin@gmail.com>; wrote:

> Understood - I assume other push services may have similar restrictions,
> and in general TLS client
> auth is tricky on both client and server side.
>
> That leaves 2.3 only ? I think it's ok - it relies on the same thing as
> TLS client auth, the sender
> signing with the private key, and push service checking it against the
> public key provided at subscribe time.
> Can we at least make it consistent with the the encryption - i.e. use the
> same type of key ?
> In particular it would be nice if an app instance (A) could even use the
> public key of another instance (B),
> to allow B to send messages directly to A, without using the app server (
> for a future version of the
> standard, of course - but we should keep it in mind ).
>
>
>
> Costin
>
> On Wed, Jan 6, 2016 at 8:33 AM, jr conlin <jconlin@mozilla.com>; wrote:
>
>>
>>
>> On 01/06/2016 01:16 AM, Martin Thomson wrote:
>>
>>> On 6 January 2016 at 15:55, Costin Manolache <costin@gmail.com>; wrote:
>>>
>>>> For authentication:  2.1(certificate) would be my preference, and is a
>>>> well
>>>> known and established
>>>> mechanism, followed by 2.6, 2.3.
>>>>
>>> Both 2.1 (certs) and 2.6 (token binding) require access to the TLS
>>> connection.  Token binding has the added concern that it is a new
>>> mechanism that might not be well deployed.
>>>
>>> When I inquired, certs did seem possible, but Mozilla folks (JR can
>>> speak to this better than I), had some operational concerns.  JWT
>>> hoists the authentication information up into HTTP, which was a lot
>>> easier to manage.
>>>
>> We are currently deployed on Amazon Web Services (AWS) using Elastic Load
>> Balancers (ELBs) to terminate TLS connections for both cost and performance
>> reasons. The ELBs act as a simple proxy, consume the certificate and
>> provide no certificate information. AWS has no plans to modify ELB software
>> to relay the cert information as part of the proxied connection. It is not
>> possible for any AWS based service to use any cert information to show
>> authentication, since it is impossible to get that information.
>>
>>
>>
>> _______________________________________________
>> Webpush mailing list
>> Webpush@ietf.org
>> https://www.ietf.org/mailman/listinfo/webpush
>>
>
>
> _______________________________________________
> Webpush mailing list
> Webpush@ietf.org
> https://www.ietf.org/mailman/listinfo/webpush
>
>