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

[Ben Campbell <[e-mail]>]

> On Jan 9, 2019, at 9:28 AM, Christer Holmberg <[e-mail]> wrote:
> 
> 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?

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.

> 
> ---------------------------------------------------------------------------
> 
> §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.
> 

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

> Regards,
> 
> Christer
>