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

[Benjamin Kaduk <[e-mail]>]

On Sun, Jan 06, 2019 at 04:10:11PM +0000, Christer Holmberg wrote:
> Hi,
> 
> 
> For some reasons all replies were not delivered to me yesterday, but I hope I am now replying to the latest one.
> 
> 
> …
> 
> 
> 
> >>>>> 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.
> 
> As indicated yesterday, I would be happy to add such text.
> 
> >>>>> 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.
> 
> What about something like the following:

The general trend is looking good.  I'll probably have some wordsmithing
suggestions for "TLS MUST be used, unless [...]" in my ballot but don't
have a great suggestion right now.

-Benjamin

> OLD:
> 
>    "Operators MUST ensure that the SIP signalling is properly secured,
>    e.g., using encryption, from malicious middlemen.  TLS MUST be used,
>    unless the operators know that the signalling is secured using some
>    other mechanism.
> 
>    [RFC8292] defines a mechanism which allows a proxy to identity itself
>    to a PNS, by signing a JWT sent to the PNS using a key pair.  The
>    public key serves as an identifier of the proxy, and can be used by
>    devices to restrict push notifications to the proxy associated with
>    the key."
> 
> NEW:
> 
>   "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 the PNS defined in that specification. Security considerations
>     for other PNSs are left to their respective specifications.
> 
>    Operators MUST ensure that the SIP signalling is properly secured,
>    e.g., using encryption, from malicious middlemen.  TLS MUST be used,
>    unless the operators know that the signalling is secured using some
>    other mechanism that provides strong crypto properties.
> 
>    Unless the PNS authenticates and authorizes the PNS, malicious users that managed
>    to get access to the parameters transported in the SIP signalling might be able to
>    request push notifications towards a UA. Which such push notifications will not
>    have any security related impacts, they will impact the battery life of the UA and trigger
>    unnecessary SIP traffic.
> 
>    [RFC8292] defines a mechanism which allows a proxy to identity itself
>    to a PNS, by signing a JWT sent to the PNS using a key pair.  The
>    public key serves as an identifier of the proxy, and can be used by
>    devices to restrict push notifications to the proxy associated with
>    the key."
> 
> Regards,
> 
> Christer
>