Subject: Re: [sipcore] Adam Roach's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the DISCUSS issues Part 2

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 15:28:13 +0000

Hi,

I realized there were DISCUSS issues that I didn't address in my previous reply. I will address them in this reply.

§4.1:

>>  For privacy and security reasons, the UA MUST NOT include the SIP URI  
>> parameters defined in this document in non-REGISTER request, to  
>> prevent the PNS information associated with the UA from reaching the  
>> remote peer.
>
> This seems to ignore the availability of Contact URI parameters via RFC 3680 subscriptions. This would seem to impose a requirement on Registrars to 
> strip this information before making it available to any other party (which, in turn, requires that the system have explicit Registrar *and* Proxy support).
> As far as I can tell, the system so far has not required explicit proxy support (and there's certainly no mechanism built-in that ensures that a proxy has any 
> special handling regarding this mechanism).
>
> If the PNS information is sensitive, and cannot be allowed to leak out to other users, then we need some way to ensure the registrar has provided positive 
> confirmation that it will not do so before allowing it to come into possession of them.

Users aren't normally allowed to subscribe to the Contacts of other users, are they? And, if they were, I don't think the PNS information is the only information that would be considered sensitive.

But, to answer your question, I don't know how to prevent that, other than adding text to the security considerations saying that operators must take this into consideration.

---------------------------------------------------------------------------

§4.2:

>>  The UA can do so by only including the pn-provider  SIP URI parameter 
>> in the SIP Contact header field URI of the REGISTER  request, but 
>> without including the pn-prid SIP URI parameter.
>
> Unless I'm mistaken, this is a barrier to interoperation.
>
> It's not 100% clear, but I suspect the intended implication is that the pn-provider parameter here will contain a single value? The syntax of the parameter 
> certainly seems to imply that. This seems to be a pretty big problem, since it presupposes that the client will know which PNSes the Proxy supports.  
> Consider, for example, an iOS client that can use any of RFC 8030, FCM, and APN (cf https://firebase.google.com/docs/cloud-messaging/ios/client).
> If the client doesn't know a priori what the proxy supports (and this entire section only makes sense if that's true), then it won't know which of those 
> three services to indicate in its REGISTER request. If it guesses wrong, this mechanism simply fails.
>
> I think you need a different discovery mechanism here -- either have one that has the client offering multiple PNS protocols and the proxy responding 
> with one, or have one in which the proxy indicates all of its supported services in a response, and the client chooses one to use in its next REGISTER message.

I suggest the first option, where the client can offer multiple PNS protocols (pn-provider values) and the proxy responds with one. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Jan 2019 12:06:18 -0500

> I suggest the first option, where the client can offer multiple PNS protocols (pn-provider values) and the proxy responds with one.

There could be a situation where there are multiple proxies on the path, 
each supporting a different mechanism. Then what happens? Does the first 
proxy "win", or the last one?

If this starts with the proxies each indicating their support, then the 
client gets to choose the one he prefers. This also means the client 
doesn't need to include any additional information until it knows that 
it will be supported. Of course this requires a double registration at 
startup, but considering the number of register requests that will be 
used during the session this doesn't seem a huge burden.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 17:24:17 +0000

Hi,

>>> I think you need a different discovery mechanism here -- either have 
>>> one that has the client offering multiple PNS protocols and the proxy responding with one, or have one in 
>>> which the proxy indicates all of its supported services in a response, and the client chooses one to use in its next REGISTER message.
>> 
> There could be a situation where there are multiple proxies on the path, each supporting a different mechanism. 
> Then what happens? Does the first proxy "win", or the last one?
>
> If this starts with the proxies each indicating their support, then the client gets to choose the one he prefers. This also 
> means the client doesn't need to include any additional information until it knows that it will be supported. Of course this 
> requires a double registration at startup, but considering the number of register requests that will be used during the session 
> this doesn't seem a huge burden.

If a proxy has indicated support of push, another proxy should not do it. The current syntax doesn't allow it.

Also, I am not aware of any scenario where there would be multiple proxies supporting push, so I don't think it is a real-life issue. Even if a network support multiple PNSs, they will all be handled by the same proxy.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 18:27:02 +0000

Hi,

Follow-up to my previous reply at the end.

>>>> one that has the client offering multiple PNS protocols and the 
>>>> proxy responding with one, or have one in which the proxy indicates all of its supported services in a response, and the client chooses one to use in its next REGISTER message.
>>> 
>> If this starts with the proxies each indicating their support, then 
>> the client gets to choose the one he prefers. This also means the 
>> client doesn't need to include any additional information until it 
>> knows that it will be supported. Of course this requires a double 
>> registration at startup, but considering the number of register requests 
>> that will be used during the session this doesn't seem a huge burden.
>

I was mixing up the parameters. The syntax does allow indicating support of multiple PNS.

But, the procedures are based on the assumption that only one proxy inserts PNS information, and I don't think we should change that.

And, as I said in my previous e-mail, in all cases I am aware of there is anyway only one proxy doing the PNS stuff.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 18:35:03 +0000

Hi,

A follow-up on one issues.

§4.2:

>>>  The UA can do so by only including the pn-provider  SIP URI 
>>> parameter in the SIP Contact header field URI of the REGISTER  
>>> request, but without including the pn-prid SIP URI parameter.
>>
>> It's not 100% clear, but I suspect the intended implication is that 
>> the pn-provider parameter here will contain a single value? The syntax of the 
>> parameter certainly seems to imply that. This seems to be a pretty big problem, since 
>> it presupposes that the client will know which PNSes the Proxy supports.
>> If the client doesn't know a priori what the proxy supports (and this 
>> entire section only makes sense if that's true), then it won't know which of those three services to 
>> indicate in its REGISTER request. If it guesses wrong, this mechanism simply fails.
>>

The text in the draft says:

"The proxy MUST indicate support only of the same PNS that was identified
 in the pn-provider SIP URI parameter in the REGISTER request."

So, in the query case, if the UA indicates support of multiple PNS, I guess the proxy could do the same. The UA will then choose one.

I assume what you meant with your second alternative is that a proxy would indicate every PNS it supports no matter what the UA indicates. I could live with that. In that case we don't need to change the syntax of pn-provider - we could say that the single PNS indicated by the UA is the "preferred one", or something like that.

Regards,

Christer

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Wed, 9 Jan 2019 13:27:01 -0600

> On Jan 9, 2019, at 9:28 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> Users aren't normally allowed to subscribe to the Contacts of other users, are they?

As far as I know, that’s an operational choice, not a requirement. One assumes that if 3680 is used, _someone_ is subscribing.

> And, if they were, I don't think the PNS information is the only information that would be considered sensitive.

True, but this draft should take responsibility for the data elements that it adds.

> But, to answer your question, I don't know how to prevent that, other than adding text to the security considerations saying that operators must take this into consideration.

I’m on the fence as to whether we should expect the registrar to strip PNS, vs just mention that information can be leaked this way. The WG might need to think a bit harder about how sensitive the PNS really is. I think we were prohibiting it in non-REGISTER requests somewhat opportunistically (that is, because it was easy to do), not because we had really analyzed the privacy implications.

Would that require the UA to preemptively register will all possible PNSs, even if it’s only going to use one?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Jan 2019 19:51:38 +0000

Hi,

§4.1:
 
>>>> For privacy and security reasons, the UA MUST NOT include the SIP 
>>>> URI parameters defined in this document in non-REGISTER request, to 
>>> This seems to ignore the availability of Contact URI parameters via 
>>> RFC 3680 subscriptions. This would seem to impose a requirement on Registrars to strip this 
>>> information before making it available to any other party (which, in turn, requires that the system have explicit Registrar *and* Proxy support).
>>> As far as I can tell, the system so far has not required explicit 
>>> proxy support (and there's certainly no mechanism built-in that ensures that a proxy has any special handling regarding this mechanism).
>>> 
>>> If the PNS information is sensitive, and cannot be allowed to leak out to other users, then we need some way to ensure the registrar 
>>> has provided positive confirmation that it will not do so before allowing it to come into possession of them.
>> 

Yes, but I would assume it is controlled who is allowed to subscribe to what.

> True, but this draft should take responsibility for the data elements that it adds.

Absolutely, but in general I think this is more of an 3680 issue. Or, have we always assumed that whatever is placed in the contact is non-sensitive?

> I’m on the fence as to whether we should expect the registrar to strip PNS, vs just mention that information can be leaked this way. 
> The WG might need to think a bit harder about how sensitive the PNS really is. I think we were prohibiting it in non-REGISTER requests somewhat 
> opportunistically (that is, because it was easy to do), not because we had really analyzed the privacy implications.

It may vary between PNS, but in general I would assume that the most sensitive information is the PRID. However, it is not sensitive because it would provide user information (afaik it is just a unique random string), but because it could potentially be used to trigger malicious push notifications. Now, in addition to the PRID, whoever acts like the proxy also needs to authenticate itself with the PNS, so one will know where the push notification requests come from. Also, mechanisms like VAPID can be used to control who is allowed to trigger push notifications.

§4.2:
 
>>> the pn-provider parameter here will contain a single value? The syntax of the parameter certainly seems to imply that. 
>>> This seems to be a pretty big problem, since it presupposes that the client will know which PNSes the Proxy supports.
>>> entire section only makes sense if that's true), then it won't know which of those three services to indicate in its REGISTER request. If it guesses wrong, this mechanism simply fails.
>>> 
>>> one that has the client offering multiple PNS protocols and the proxy responding with one, or have one in which the proxy
>>> indicates all of its supported services in a response, and the client chooses one to use in its next REGISTER message.
>> 

Not as far as the SIP push mechanism in concerned, because when the UA does a query it doesn't need to provide PRID (which it receives during PNS registration), it only indicates the PNS(s) it supports.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Jan 2019 17:16:20 -0500

> Also, I am not aware of any scenario where there would be multiple proxies supporting push, so I don't think it is a real-life issue. Even if a network support multiple PNSs, they will all be handl…

That seems unfortunate. It may be that there is no single proxy 
implementation that supports all the different, while there might not be 
a single PNS that all the clients support. What is the deployment to do 
in that case? Deploying multiple proxies on the path, supporting 
different PNSs would be a solution. It wouldn't be too burdensome 
because only the chosen one would need to stay on the path.

But apparently that option is currently not supported.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jan 2019 09:27:11 +0000

Hi,

>>>>> one that has the client offering multiple PNS protocols and the proxy
>>>>> responding with one, or have one in which the proxy indicates all of its
>>>>> supported services in a response, and the client chooses one to use in
>>>>> its next REGISTER message.
>>>>
>>>> I suggest the first option, where the client can offer multiple PNS protocols
>>>> (pn-provider values) and the proxy responds with one.
>>>
>>> If this starts with the proxies each indicating their support, then the client gets
>>> to choose the one he prefers. This also means the client doesn't need to include
>>> any additional information until it knows that it will be supported. Of course this
>>> requires a double registration at startup, but considering the number of register
>>> requests that will be used during the session this doesn't seem a huge burden.
>>
>> Also, I am not aware of any scenario where there would be multiple proxies supporting
>> push, so I don't think it is a real-life issue. Even if a network support multiple PNSs, they
>> will all be handled by the same proxy.
>

Yes, it is. If a proxy receives a REGISTER with an indication of a PNS that it does not support, the current solution DOES allow it to forward the REGISTER request, if it "knows" that another proxy might support the PNS.

But, some operators do not want the REGISTER to reach the registrar if no proxy supports the PNS.

So, an operator can configure its network to act in a desired way.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2019 10:35:12 -0500

On 1/10/19 4:27 AM, Christer Holmberg wrote:

> Yes, it is. If a proxy receives a REGISTER with an indication of a PNS 
> that it does not support, the current solution DOES allow it to forward 
> the REGISTER request, if it "knows" that another proxy might support the 
> PNS.

What if the client supports multiple PNSs, and doesn't know which is 
supported by this registrar and associated proxies? Can it indicate 
support for multiple PNSs - allowing the proxies to choose which one to use?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jan 2019 17:09:26 +0000

Hi,

>support for multiple PNSs - allowing the proxies to choose which one to use?

The current pn-provider syntax does not allow it, but Adam suggested that we should allow the UA to indicate support of multiple PNS.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jan 2019 12:25:00 -0500

On 1/10/19 12:09 PM, Christer Holmberg wrote:

> The current pn-provider syntax does not allow it, but Adam suggested 
> that we should allow the UA to indicate support of multiple PNS.

That would help. Then, if more than one PNS is supported, but by 
different proxies, then IIUC:

- the request MAY get passed along to the first proxy that supports one 
of the named PNSs. It will take it and the others are not considered.

- OR, a proxy that supports a different PNS than any the client supports 
may reject the request without allowing a later proxy to accept it.

Do I have that right?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jan 2019 17:34:59 +0000

Hi,

>of the named PNSs. It will take it and the others are not considered.

Correct.

>may reject the request without allowing a later proxy to accept it.

Correct.

>Do I have that right?

Yes.

That is also what the current procedures say. However, they only talk about the UA indicating support of a single PNS, so we would need to change that to allow the UA to indicate support of multiple PNS.

Regards,

Christer

        Thanks,
        Paul