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

[Benjamin Kaduk <[e-mail]>]

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

-Benjamin