Re: [Webpush] Application server authentication new years edition

Costin Manolache <costin@gmail.com> Wed, 06 January 2016 19:30 UTC

Return-Path: <costin@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 DE99A1A0143 for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 11:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 dWxIA7BLGeS7 for <webpush@ietfa.amsl.com>; Wed, 6 Jan 2016 11:30:00 -0800 (PST)
Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 C77B71A011C for <webpush@ietf.org>; Wed, 6 Jan 2016 11:29:59 -0800 (PST)
Received: by mail-ob0-x235.google.com with SMTP id bx1so280893260obb.0 for <webpush@ietf.org>; Wed, 06 Jan 2016 11:29:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XKXJjeHmrj3jwS2HSjZEcqZld5fyS0BQ+vc4Z8FK6No=; b=YvVCwtpd68pzjXCeBq+A3HjBQXcZMt0OHdb6/VkYziKC9w3cLc1NOnhZonL6rOxO1o lBnuOqt7TFoZ6/5VvAWljihs+EsS8LkZ7UYMzuqaMtm7nAIqb0iT6bADhIUlK2fXQ9KL X4Nt94epKWPD9RlH9DcMS4W+1vSvbKVqkDGmlg2HGsrkAcuGHgmL8S6hog5zHZSZN9F6 0t1VoH4G50eDqqljDkcQBz0tTtJ7/tbRc73tdB5TQA1ueOjGEaHg18BFfclHBUCLleaj N4ciR2ojP1EIsNiwLbC4vrcYR1vbHlvsVvI52dXAdmAPOU9t/y279r6IH8UlKkD8LRZj vhpA==
MIME-Version: 1.0
X-Received: by 10.182.200.201 with SMTP id ju9mr71164683obc.30.1452108599207; Wed, 06 Jan 2016 11:29:59 -0800 (PST)
Received: by 10.76.8.74 with HTTP; Wed, 6 Jan 2016 11:29:59 -0800 (PST)
In-Reply-To: <568D41D6.40904@mozilla.com>
References: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com> <CAP8-Fq=PhUcj5aaE6dvF2_+-HmVrGDyk41QBzkVxiNMxUakoag@mail.gmail.com> <CABkgnnUYkuu9pjuqLDhiWLNWzkr9ZfYRNny4ZvSKRTWie2bQyA@mail.gmail.com> <568D41D6.40904@mozilla.com>
Date: Wed, 6 Jan 2016 11:29:59 -0800
Message-ID: <CAP8-FqnnYtQrBbngna5a6PqfXxawq-ORh-HFA85tJ56VsNd=LA@mail.gmail.com>
From: Costin Manolache <costin@gmail.com>
To: jr conlin <jconlin@mozilla.com>
Content-Type: multipart/alternative; boundary=001a11c252843b356c0528af614b
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/e5TKldphhXbZWj1PB1vzDHXTG5k>
Cc: "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 19:30:02 -0000

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
>