Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21

[Ben Campbell <[e-mail]>]

> On Jan 5, 2019, at 1:33 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> On Sat, Jan 05, 2019 at 01:19:27PM -0600, Ben Campbell wrote:
>> 
>> 
>>> On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk <[e-mail]> wrote:
>>> 
>>> [with the caveat that I've only read the security considerations and not
>>> the whole document, yet...]
>>> 
>>> On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote:
>>>> (Speaking as responsible ART AD)
>>>> 
>>>> I will let Christer work through most of the comments, but I want to comment on one in particular:
>>>> 
>>>>> On Jan 4, 2019, at 1:46 PM, Scott G. Kelly <[e-mail]> wrote:
>>>>> 
>>>>> I don't know what other documents have been produced by the WG, so maybe this is covered elsewhere, but there are generic security considerations that apply abstractly to this use case. I think this document should either point to documents that describe them, or explicitly describe them here. For example, 8030 lists confidentiality with respect to the PNS, privacy considerations, authorization, DoS, and logging risks. All of those apply here.
>>>> 
>>>> 
>>>> This draft is about how to carry some parameters in SIP that get used with an external PNS. It should definitely document security considerations related to carrying those parameters. But I don’t think it’s reasonable to expect this draft to document security considerations for PNSs in general. That’s up to the spec for the PNS itself. I recognize that two of the mentioned PNSs are proprietary; but I still don’t think that puts the onus on the IETF to document their security considerations.
>>> 
>>> I agree that we don't need to document all general PNS security
>>> considerations here, but just because an interaction is PNS-specific does
>>> not excuse us from stating what requirements we place on that interaction.
>>> It is rather unreassuring to read statements like "[d]ifferent mechanisms
>>> exist for authenticating and authorizing devices and users registering with
>>> a PNS" and "[t]ypically, the PNS also requires the SIP proxy requesting
>>> push notifications to be authenticated and authorized by the PNS" with no
>>> requirement that such authentication and authorization actually occur.
>>> I would expect to see either a requirement for such
>>> authentication/authorization, or some indication of what risks are present
>>> when they do not (e.g., excessive resource consumption, DoS)
>>> 
>> 
>> The issue is, the IETF doesn't get to put requirements on proprietary PNSs mechanisms, and 2 of the 3 that we are considering are proprietary. The whole point of this is to allow SIP networks to work with the existing PNSs. They are what they are. SIP providers would not be able to use our recommendations to select which PNSs to use; rather they must use the ones that their customers’ devices already use.
>> 
>> Obviously we can say more for HTTP Push; RFC 8030 already does that.
>> 
>>>> The categories you mention from 8030 do seem generic, but the text in the respective sections of 8030 seems fairly specific to HTTP(S) Push.
>>>> 
>>>> That all being said, I would be happy to see something to the effect of the following in this draft: “The security considerations for the use and operation of any particular PNS is out of scope for this document. [RFC8030] documents the security considerations for HTTP Push. Security considerations for other PNSs are left to their respective specifications.”
>>> 
>>> That seems like a pretty nice way to say it.
>> 
>> Would that be sufficient to resolve your concern above?
> 
> I think I would still like to see some indication of the potential
> consequences for the mechanism defined in this document, if a PNS does not
> (properly) perform authentication and authorization between UA/proxy and
> PNS.
> 
> (Having not yet read the whole spec I don't have a great picture of
> exactly what those consequences are.)
> 

That’s reasonable, and I think fits into the category of consequences to the SIP network due to the interface.

Thinking out loud: One thing that comes to mind would be the insertion of false push notifications by an unauthorized 3rd party. It seems like the 3rd party would have to learn the necessary parameters, which might be difficult. How guessable these parameters might be would have an impact.

If someone succeeded in this, I imagine it mostly as a DoS attack on handset battery life. It could possibly be a DoS on the registrar.

From a privacy perspective, an eavesdropper might be able to infer something about the number of incoming calls to a handset. Hopefully there’s not much in the way of PSI in the push request or notification themselves.

Ben.