Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Martin's comments - VAPID

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Feb 2018 15:04:19 +0000

Hi,

I have done some quick studying on VAPID. Some of the statements I make below may be false, so feel free to correct me.

First, Martin earlier said that "FCM insists on RFC 8292 authentication". Is this really true? As far as I know, the usage of VAPID is optional. Also, I haven't been able to find any documentation regarding usage of VAPID in native Android applications. Most seem to be related to browser apps. Do Android native apps even create connections to FCM servers, or is it done by the operating system (and the used by the native apps)?

If we add support of VAPID, it doesn't really matter whether it's mandatory or not - I just want to clarify.

Second, the usage of VAPID is indicated when registering to the FCM service.  In the case of a SIP app, that is done BEFORE the SIP REGISTER is sent (read: before the SIP proxy can provid the key etc needed for VAPID), possibly before it is even known what SIP proxy will be used. Of course, in some cases this information may be locally configured in the device.

Anyway, in order to allow the SIP proxy to provide the VAPID information to the device using SIP, we could define a feature-capability indicator (e.g., "sip.vapid"), which contains the key etc. The SIP proxy could include that in the REGISTER response (and, if needed, in other SIP messages too).

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 06 February 2018 23:35
To: Christer Holmberg <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Martin's comments

On Wed, Feb 7, 2018 at 2:17 AM, Christer Holmberg <[email-masked]> wrote:
> It is true that push services require the proxy to be authenticated by the push service. And, in case the UA needs to provide some information to the proxy in order to do that authentication, it can use the pn-param for that. When registering a new provider value, one needs to specify what (if any) additional information is provided by the UA to the proxy.

The other way around.  The proxy needs to provide its identity or public key to the UA so that the UA can tell the push service who is permitted to send messages.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Feb 2018 08:31:13 +1100

> If we add support of VAPID, it doesn't really matter whether it's mandatory or not - I just want to clarify.

Yes, FCM requires that the subscription be restricted to a single
application server key.  (I think that there is a different API for
getting an 8030 subscription, but I haven't looked into the details.)

> Second, the usage of VAPID is indicated when registering to the FCM service.  In the case of a SIP app, that is done BEFORE the SIP REGISTER is sent (read: before the SIP proxy can provid the key e…

Correct.

> Anyway, in order to allow the SIP proxy to provide the VAPID information to the device using SIP, we could define a feature-capability indicator (e.g., "sip.vapid"), which contains the key etc. The…

Do what you gotta.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Feb 2018 09:14:01 +0000

Hi Martin (and others),

Spent time in the air trying to put together some text on how to implement VAPID support in SIP push.

I will add it to the pull request later, but please take a look and see whether this is anything like what you had in mind :)

(The IANA stuff will also be added)

7.x.  sip.vapid Feature-Capability Indicator
--------------------------------------------------------

   The sip.pns feature-capability indicator is used in a SIP 200 (OK)
   Response to a SIP REGISTER request to indicate support of the
   the Voluntary Application Server Identification (VAPID) [RFC8292] 
   mechanism when requesting push requests associated with the 
   SIP registration.

     vapid-fc          = "+sip.vapid" EQUAL LDQUOT vapid RDQUOT
     vapid             = tag-value

     ; tag-value as defined in RFC 3840

     The value of the feature-capability indicator is the public key of the SIP proxy, which can
     be used by a SIP UA to restrict subscriptions to that SIP proxy [RFC8292]. 

New text to section 4 (SIP UA behaviour):
-------------------------------------------------------

NEW:

   In addition, if the response contains a Feature-Caps header field with
   a '+sip.vapid' header field parameter, and if the PNS provider supports
   the VAPID mechanism, the UA can use the header field parameter
   value (a public key) to restrict push notifications from 
   the proxy associated with the public key.

Modified 2nd paragraph in section 5.3:
----------------------------------------------------

OLD (possible changes to the text based on other WGLC comments not shown):

   If the SIP proxy supports the pn-provider SIP URI parameter value,
   when the proxy receives (or, in case the proxy is the SIP registrar,
   creates) a 200 (OK) response to the REGISTER request, the proxy MUST
   insert a Feature-Caps header field with a '+sip.pns' header field
   parameter in the response, in order to inform the SIP UA that the
   proxy supports the PNS indicated by the pn-provider SIP URI parameter
   value.

NEW:

   If the SIP proxy supports the pn-provider SIP URI parameter value,
   when the proxy receives (or, in case the proxy is the SIP registrar,
   creates) a 200 (OK) response to the REGISTER request, the proxy MUST
   insert a Feature-Caps header field with a '+sip.pns' header field
   parameter in the response, in order to inform the SIP UA that the
   proxy supports, and will use, the PNS indicated by the pn-provider 
   SIP URI parameter value. In addition, if the SIP proxy supports, and will use, 
   the VAPID mechanism when triggering push notifications, the proxy 
   MUST insert a Feature-Caps header field with a '+sip.vapid' header field 
   parameter in the response. The header field parameter value is the 
   public key value of the proxy, which the SIP UA can use to restrict push 
   notifications from the specific proxy [RFC8292].

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 07 February 2018 23:31
To: Christer Holmberg <[email-masked]>
Cc: Dale R. Worley <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Martin's comments - VAPID

> If we add support of VAPID, it doesn't really matter whether it's mandatory or not - I just want to clarify.

Yes, FCM requires that the subscription be restricted to a single application server key.  (I think that there is a different API for getting an 8030 subscription, but I haven't looked into the details.)

Correct.

Do what you gotta.