Re: [Webpush] Application server authentication new years edition

[Costin Manolache <[e-mail]>]

On Wed, Jan 6, 2016 at 7:29 PM, Martin Thomson <[e-mail]>
wrote:

> Mega-multi-response.
>
> On 7 January 2016 at 05:01, Costin Manolache <[e-mail]> wrote:
> > At the same time you can't force push service providers to accept
> >  unauthenticated/unauthorized sending either. Or require them to
> > provide unlimited (and free) service to everyone regardless of how much
> > they're abusing/hurting users or networks.
>
> The authorization question is challenging, particularly when it comes
> to abuse of limited resources (user attention, battery power, push
> service capacity).  It would be good to understand what the invariants
> are on each service.
>
> If Google are unwilling to allow completely unauthenticated requests,
> then I think that we could insist on something voluntary.  I'm
> reluctant to do that because it makes it more difficult for
> application server developers to get a start, but that can be mitigate
> with good tooling, I guess.
>
> On the other hand, if there are cases where a small number of requests
> can be made without extra authentication, then the proposed option
> would be ideal.  That would allow people to experiment a little before
> having to tool up.
>

Completely unauthenticated requests would be an extremely hard sell, and
I suspect other push services will be in the same position (at least after
some
time).

Also I don't think developers would benefit much - generating a signed
JWT token is much simpler than encryption, and it already has plenty of
libraries.

And it won't benefit them too much to start an app without authentication,
than
get random rejections or errors - or worse, launch it and than realizing it
doesn't work.
We had a period of 'free quota/contact us if you need more' - it was not
fun.



> > How about 2.1 AND 2.3 ? Push servers should support both, clients
> > should use what they can.
>
> I'd like to avoid that situation because it hurts a lot more all
> around.  We like to save that option for the really tough problems
> (video codecs, for example).
>

I think the fact TLS client auth doesn't work on some providers is enough
to kill it
at least for this version, I didn't know it's not supported.

That leaves 2.3 only.


>
> > And it may be the way to allow the choice on app server side - either by
> > having an 'isAuthorizationRequired()' or an error code when attempting to
> > subscribe without a public key.
>
> Again, that makes it more difficult to use the API, and I'd be very
> reluctant to take that option unless the alternatives are untenable.
>

I agree - IMHO just passing the sender key for all providers is cleanest
and least
risky option.



>
> On 7 January 2016 at 06:29, Costin Manolache <[e-mail]> wrote:
> > 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 ?
>
> We can certainly use P-256 for that as well; that's what is proposed.
> However, it would need to be a different key pair, since all the
> experts recommend against using the same key for signing and key
> exchange.  (There isn't an actual attack, but the dual use isn't
> provably safe.)
>

I know it's recommended, but it would be very convenient for device2device
 to be able to use the public key generated by subscribe.

In any case, the UA will need to provide some special API to send() or just
an API to
sign or generate JWT token - it could generate a second key for
authentication.



>
> On 7 January 2016 at 12:43, Costin Manolache <[e-mail]> wrote:
> > 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.
>
> I very much agree with this sentiment.  That contact information can
> be verified, though I think that we should probably start out by
> relying on manual processes for that.  We can layer other mechanisms
> on top.
>
> I'm not particularly fond of the idea of using something as
> heavyweight as what Ben suggested.  Something much simpler might work,
> but I don't think that we need that.  An absolute requirement to use
> something that that would be a big problem.
>

Agreed, and while his suggestion would work for checking the contact info,
it will still
not be enough for possible charging providers, or for providers offering
dashboards or
other tools. Better to keep verification and association of the public key
with a
'real' account as out of scope of this draft.

Costin


>
> On 7 January 2016 at 13:11, Benjamin Bangert <[e-mail]> wrote:
> > Right, that this is not strongly authenticated means we can't do
> something
> > like build a developer dashboard that might expose notification traffic
> > information associated with the JWT. ie, if a Push Service wanted to
> provide
> > developers with a diagnostic dashboard similar to what GCM Diagnostics
> > provides GCM users.
>
> If this is your concern, why not ask the dashboard user to prove that
> they have access to the JWK private key when logging in?  That's
> relatively easy to do.  You don't actually need to know who they are
> in that case.  (Though you could use the dashboard UI to do things
> like email verification, as many sites do.)
>