Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Security Considerations

From: Christer Holmberg <[email-masked]>
Date: Sun, 4 Feb 2018 15:25:42 +0000

Hi,

I modified the Security Considerations. It now contains more text regarding authentication and authorization of devices, SIP applications and SIP proxies.

NEW:

"PNS providers offer different mechanism for authenticating and authorizing devices and users registering to the PNS provider. The mechanisms for authorizing and authenticating the users are PNS-specific, and are outside the scope of this document. In addition to the information that needs to be exchanged between a device and the PNS provider in order to establish a push notification subscription, the mechanism defined in this document does not require any additional information to be exchanged between the device and the PNS provider.

Typically, the PNS provider also requires the SIP proxy requesting push notifications to be authenticated and authorized by the PNS provider. In some cases the PNS provider also require the SIP application (or the SIP application developer) to be identified in order for the application to request push notifications.

If the push notification related information carried in SIP could be used by a malicious user to trigger push notifications towards a device, operators MUST ensure that the SIP signalling in which the information is carried properly secured from malicious middlemen. In some cases the information carried in SIP cannot alone be used to request a push notification, as the SIP proxy requesting the push notification also needs to be authenticated and authorized by the PNS provider. However, even in such cases the information carried in SIP needs to be properly protected, in order to prevent a middleman from modifying the information in a way that would result in push notifications being sent towards non-intended devices. Some PNS providers allow device users to restrict which SIP proxies are allowed to trigger push notifications towards the device.

The mechanism in this document does not require a SIP proxy to include any payload (in addition to possible payload used for the PNS itself) when requesting push notifications.  However, in case a SIP proxy do want to include payload in push notifications, this specification defines the means for using end-to-end payload encryption between the SIP proxy requesting the push notification and the device receiving it."

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Feb 2018 11:17:17 +1100

This really needs a reference to RFC 8292.  That describes an
interoperable system for identification of the proxy.

On Mon, Feb 5, 2018 at 2:25 AM, Christer Holmberg
<[email-masked]> wrote:
> “PNS providers offer different mechanism for authenticating and authorizing

mechanism*s*

> If the push notification related information carried in SIP could be used by
> a malicious user to trigger push notifications towards a device, operators
> MUST ensure that the SIP signalling in which the information is carried
> properly secured from malicious middlemen.

What does this mean?  I think that you mean use TLS for signaling,
authenticate your proxy and don't send this to anyone else.  If you
plan to use UDP, then we have some serious issues.  Then you
definitely need something like what is described in Section 4 of 8292
(https://tools.ietf.org/html/rfc8292#section-4), as MTI ideally.
Windmilling arms like this doesn't really get the outcome you want.

> The mechanism in this document does not require a SIP proxy to include any
> payload (in addition to possible payload used for the PNS itself) when
> requesting push notifications.  However, in case a SIP proxy do want to
> include payload in push notifications, this specification defines the means
> for using end-to-end payload encryption between the SIP proxy requesting the
> push notification and the device receiving it.”

As I said in my review, there isn't any value in defining a mechanism
if the thing that it exists to support isn't defined.  Do you have a
use for push message payloads?

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Feb 2018 23:11:03 -0500

Christer Holmberg <[email-masked]> writes:
> I modified the Security Considerations. It now contains more text
> regarding authentication and authorization of devices, SIP
> applications and SIP proxies.

I did a quick read of this new text, and I don't think it is
sufficient.  It doesn't really define any mechanisms, so there's no way
to implement it.  And the only security it considers is for the SIP
proxy (or presumably registrar in a purist implmentation) it
authenticate *itself* to the notification service.  But the core problem
is that the UA needs to attach authentication to its push
registration -- it doesn't matter of the service knows that the proxy is
who it claims to be if the proxy is passing on bogus registrations.

I don't think that this will even be workable in existing 3GPP
situations, where the proxy has good authentication of the UA, because
the proxy has no way to enforce that the UA only registers to PRIDs that
it has established.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 04:28:55 +0000

Hi,

> I did a quick read of this new text, and I don't think it is sufficient.  It doesn't really define any mechanisms, so there's no way to implement it.  

Each push notification mechanism has its own way of providing authentication and authorization, and if you are implementing an push notification client for a specific push notification service you need to implement the authentication/authorization associated with that push notification service.

> And the only security it considers is for the SIP proxy (or presumably registrar in a purist implmentation) it authenticate *itself* to the notification 
> service.  But the core problem is that the UA needs to attach authentication to its push registration -- it doesn't matter of the service knows that 
> the proxy is who it claims to be if the proxy is passing on bogus registrations.
>
> I don't think that this will even be workable in existing 3GPP situations, where the proxy has good authentication of the UA, because the proxy
> has no way to enforce that the UA only registers to PRIDs that it has established.

This is not different from any other application using push notifications. If you are going to signal the PRID (and whatever information is needed to request push notifications) to an entity requesting push notifications, you need to protect the signalling.

Also, in the case of 3GPP, as the user is authenticated, if the user is trying to use a PRID belonging to someone else the operator will find out.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 05:29:23 +0000

Hi,

>This really needs a reference to RFC 8292.  That describes an interoperable system for 
>identification of the proxy.

I'll look into that.

>> “PNS providers offer different mechanism for authenticating and  authorizing

Will be fixed.

>> If the push notification related information carried in SIP could be 
>> used by a malicious user to trigger push notifications towards a 
>> device, operators MUST ensure that the SIP signalling in which the 
>> information is carried properly secured from malicious middlemen.
>
> What does this mean?
>  I think that you mean use TLS for signaling, authenticate your 
> proxy and don't send this to anyone else.  If you plan to use UDP, then we have some serious issues.  
> Then you definitely need something like what is described in 
> Section 4 of 8292 (https://tools.ietf.org/html/rfc8292#section-4), as MTI ideally.

I admit I haven't read 8292 in detail, so maybe I misunderstand your point, but what I meant is simply that the SIP signalling between the UA and the proxy has to be protected/encrypted.

Then, the UA will obviously have to trust that the proxy will not request non-intended push notifications.

>> The mechanism in this document does not require a SIP proxy to include 
>> any payload (in addition to possible payload used for the PNS itself) 
>> when requesting push notifications.  However, in case a SIP proxy do 
>> want to include payload in push notifications, this specification 
>> defines the means for using end-to-end payload encryption between the 
>> SIP proxy requesting the push notification and the device receiving it.”
>
> As I said in my review, there isn't any value in defining a mechanism if the thing that it exists to 
> support isn't defined.  Do you have a use for push message payloads?

No. 

So, I will remove the text and references regarding payload, and only keep the statement saying that the SIP messages must not be transported as push payload.

Regards,

Christer