Re: [Webpush] Application server authentication new years edition

Costin Manolache <costin@gmail.com> Thu, 07 January 2016 18:59 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 D50591A930A for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 10:59:50 -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 PgFXDP-J6l-v for <webpush@ietfa.amsl.com>; Thu, 7 Jan 2016 10:59:49 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 12AE61A92FD for <webpush@ietf.org>; Thu, 7 Jan 2016 10:59:49 -0800 (PST)
Received: by mail-oi0-x231.google.com with SMTP id y66so319901146oig.0 for <webpush@ietf.org>; Thu, 07 Jan 2016 10:59:49 -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=gyMy+iOsi9IsBGFt2jcqy0iCoT60HSmQVdSBjlZEbKI=; b=M7YzaGfscurjtqPHVh/fJNKdto0BnIPEGUo0VFgaH1GEKLTlubfuyczLtuRAkn0M8t j/d5QU834WbMSIpBEC2sZmt1jpxERLiNWLhxmUs5s02IrySmFUAB61Ik2ZeUeBAXOeMq LKwYH4PfvvErakUZAWZ2+RadX5P+2RstItADegXCSxrRnTBZLT8VR3ow/sNhpvLLTefg HdishBnyC8ujtwGIueN6mGe73DCMjt5GdEnl2HQ1mOiDx56BFph82ZXkRUXA+hK88Q2j jR5tPPpRrlinLrNB1P4lyrtGDPu6UY0QwgusV4Aw2i+LesaPQmBukM2kX19EvGM8q23y p6dw==
MIME-Version: 1.0
X-Received: by 10.202.201.77 with SMTP id z74mr75337587oif.24.1452193188465; Thu, 07 Jan 2016 10:59:48 -0800 (PST)
Received: by 10.76.8.74 with HTTP; Thu, 7 Jan 2016 10:59:48 -0800 (PST)
In-Reply-To: <CABkgnnW7oRTZRKDQcxf9=0f-mxKfctQQTrR5zY6q4qJtL_cPjw@mail.gmail.com>
References: <CABkgnnXBHXfY6Gz-FKGVUUoOwyJo9zaw1rWceSqVp94FypDbJA@mail.gmail.com> <CAP8-Fq=PhUcj5aaE6dvF2_+-HmVrGDyk41QBzkVxiNMxUakoag@mail.gmail.com> <CABkgnnUYkuu9pjuqLDhiWLNWzkr9ZfYRNny4ZvSKRTWie2bQyA@mail.gmail.com> <CAP8-FqnSqtMb5bT14tkycYXOOP+Xmoa9SMjuP5KkeN_ri+_NVQ@mail.gmail.com> <CABkgnnU0CP-fGpEfqLo01ZVdjT3dNVeb3MSufO1P8T2W63dNVw@mail.gmail.com> <CAP8-FqkF9X+_CjSyXB10621L0=b756REjXsbRfsL8rT6nuh9pw@mail.gmail.com> <CABkgnnW7oRTZRKDQcxf9=0f-mxKfctQQTrR5zY6q4qJtL_cPjw@mail.gmail.com>
Date: Thu, 7 Jan 2016 10:59:48 -0800
Message-ID: <CAP8-Fqnage13JQiz8Qkvrho-e8DWcw8p_NLd_xux+uQALwD7og@mail.gmail.com>
From: Costin Manolache <costin@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134f92024d3b10528c313ac
Archived-At: <http://mailarchive.ietf.org/arch/msg/webpush/fI04OQH4sORXN9cwXAYehOPPx0g>
Cc: Ben Bangert <bbangert@mozilla.com>, Costin Manolache <costin@google.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: Thu, 07 Jan 2016 18:59:51 -0000

On Wed, Jan 6, 2016 at 11:53 PM, Martin Thomson <martin.thomson@gmail.com>;
wrote:

> On 7 January 2016 at 16:43, Costin Manolache <costin@gmail.com>; wrote:
> > That leaves 2.3 only.
>
> It looks like we're mostly in agreement for something like 2.3.
> Should I take some time and flesh out the details?  Does anyone
> disagree?
>

Sounds good, but I have few questions/comments on the details.

1. Key identifiers ('kid') - for normal JWT, the key is known from the
issuer or
'sub'. Since in our case we'll have self-generated keys, and we want to
avoid
having each key registered with all providers - all that a push service
will know
when seeing a JWT token the first time will be the content of the token.
So we need a way to find the public key needed to verify the content - and
the only one I know is to use something like the SHA of the public key.
On subscribe - the provider can store the public key, with the kid as
lookup key, than
on send it can verify. For example kid == (SHA1 or SHA256 truncated to
64bits) would work.

2. 'aud' field - not sure what would be the right value, maybe the domain
of the push provider ?

3. Going back to the 'voluntary'/optional part: I'm not sure if encryption
is going to be required or
optional in the final version ?

4. I think we can have the sender key optional in the subscribe operation,
in particular for cases
like low end IOT - not including it would give permission to anyone with
the URL and pubkey
of the device to send messages. There is another case where it helps -
pairing, in cases of D2D -
but with restrictions ( either time, or binding the subscription to the
sender at first use ).
In other words: I'm not opposed to having 'optional' on the subscribe (and
on contact info).

5. This may be a bit controversial :-), if we require the developers to use
a JOSE library to
generate JWT tokens, signed with a ES256 - wouldn't make sense to also
allow them to use
the same library to encrypt the payload for the e2e ? There is already a
content type defined, so easy to
differentiate.


Costin