Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Wed, Jan 6, 2016 at 2:24 PM, Benjamin Bangert <[e-mail]>
wrote:

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

2.3 is not authenticating the contact info provided by senders, just that
sender is the same that
the UA requested.

The subscribe in the UA includes the public key of the sender, and 2.3
AFAIK strongly authenticate
the fact that the sender has access to the private key.

The contact information they chose to include in the JWT is not
authenticated at all  the push
service can only verify the sender is what the UA authorized, and can
block/throttle that sender without
affecting other 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.
>

Yes, they would also verify contact info - I have a feeling we're trying to
avoid relying too much on
the contact info ( i.e. domain name of the app server ). If the contact
info is voluntary - I don't think we need
to make it too complex by adding verification.

Rotating the identity and keys used by sender normally happens when the app
is updated, the sender can subscribe with the new key, and can use 2
subscriptions while migrating. The fact that subscriptions can be
rotated or can expire helps. Would be good to mention in the draft that a
push service that requires or accepts subscription
association (== authorization) should also allow multiple subscriptions for
an app.

I would expect verification of the sender to be useful for non-free
services - in which case the public key
 of the sender will need more than verification (i.e. will need to be
associated with a credit card :-)

Costin



>
> Cheers,
> Ben
>
> On Wed, Jan 6, 2016 at 11:29 AM, Costin Manolache <[e-mail]>
> 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 <[e-mail]> wrote:
>>
>>>
>>>
>>> On 01/06/2016 01:16 AM, Martin Thomson wrote:
>>>
>>>> On 6 January 2016 at 15:55, Costin Manolache <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/webpush
>>>
>>
>>
>> _______________________________________________
>> Webpush mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/webpush
>>
>>
>