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

[Christer Holmberg <[e-mail]>]

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

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

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

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?

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

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 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?

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