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

[Christer Holmberg <[e-mail]>]

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:

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