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

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Jan 2019 11:29:42 +0000

Hi Scott,

Thank You for the review! Please see inline.

>The summary of the review is ready with issues.
>
>The document describes how to enable a push notification service (PNS) to
>wake a suspended SIP user agent.
>
>Due to the writing style, I found the document very difficult to understand. Maybe
>the RFC editor can help with this, but it might be better if someone from the working
>group helped out with word-smithing.

I have done quite a bit of word-smithing based on WGLC/AD reviews etc, but if something is unclear I am of course very happy to fix that.

>For security considerations, there are 3 entities involved in the communications defined by this document: the >user agent (UA), the PNS server, and the application server (in this case, a SIP proxy). The basic idea is that the >UA registers with the PNS, obtaining a Push Resource ID (PRID). The UA provides the PRID to the SIP proxy, and >then the SIP proxy presents the PRID to the PNS along with a message for the UA, and the PNS uses the PRID to >route the message to the right UA.

Correct.

Note, though, that the "message" is only a push notification in order to wake up the UA. The actual SIP message (that triggered the push notification) will then be routed to the UA using normal SIP procedures.

>The security considerations section mostly punts. With respect to UA-PNS interactions, it says "The mechanisms >for authorizing and authenticating the users are PNS-specific, and are outside the scope of this document." It >says nothing about how the UA authenticates the PNS.

The UA-PNS interactions, including how the UA authenticates the PNS, are PNS specific.

>For application server (SIP proxy) to PNS interactions, it mentions the fact that a PNS may requires some sort of >authz/authn for the SIP proxy, but it gives no requirements/recommendations here. It later mentions a JWT >mechanism for this purposes described in RFC8292, but again, no requirement, no recommendation.

The proxy-PNS interactions are also PNS specific, and not defined by this document. RFC8292 is an extension that can be used with the mechanism defined in RFC8030, but it cannot be applied to any PNS on the fly. A PNS would have to explicitly support it.

>Also, it says
>
  > 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.
>
>I don't think there is a clear requirement stated here. If an operator chooses a proprietary
>scheme with weak crypto and claims that is "properly secured", have they met this requirement?

I could say something like: "is secured using some other mechanism that provides strong crypto properties".

>Finally, I think RFC8030 has a good description of the security considerations for this use case, and
>should be referenced here.

I can add a reference. However, while many of the security considerations in RFC8030 probably apply to any PNS, they are still written for a specific PNS.

Regards,

Christesr

---

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 4 Jan 2019 11:46:24 -0800 (PST)

Hi Christer,

On Thursday, January 3, 2019 3:29am, "Christer Holmberg" <[email-masked]> said:

> I have done quite a bit of word-smithing based on WGLC/AD reviews etc, but if
> something is unclear I am of course very happy to fix that.

I don't want to go through the whole document again, and I don't want to make too big a deal of this (the RFC editor has final say) but here are a few examples of things I had to read more than once to understand:

   Because of the restrictions above, Session Initiation Protocol (SIP)
   User Agents (UAs) [RFC3261] can not be awoken, in order to send
   binding-refresh SIP REGISTER requests and to receive incoming SIP
   requests, without using a PNS to wake the UA in order to perform
   those functions.

   In addition to the information that needs to be
   exchanged between a device and the PNS 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.

> 
>>For security considerations, there are 3 entities involved in the communications
>> defined by this document: the >user agent (UA), the PNS server, and the
>> application server (in this case, a SIP proxy). The basic idea is that the >UA
>> registers with the PNS, obtaining a Push Resource ID (PRID). The UA provides the
>> PRID to the SIP proxy, and >then the SIP proxy presents the PRID to the PNS along
>> with a message for the UA, and the PNS uses the PRID to >route the message to the
>> right UA.
> 
> Correct.
> 
> Note, though, that the "message" is only a push notification in order to wake up
> the UA. The actual SIP message (that triggered the push notification) will then be
> routed to the UA using normal SIP procedures.
> 
>>The security considerations section mostly punts. With respect to UA-PNS
>> interactions, it says "The mechanisms >for authorizing and authenticating the
>> users are PNS-specific, and are outside the scope of this document." It >says
>> nothing about how the UA authenticates the PNS.
> 
>>For application server (SIP proxy) to PNS interactions, it mentions the fact that
>> a PNS may requires some sort of >authz/authn for the SIP proxy, but it gives no
>> requirements/recommendations here. It later mentions a JWT >mechanism for this
>> purposes described in RFC8292, but again, no requirement, no recommendation.
> 
> The proxy-PNS interactions are also PNS specific, and not defined by this
> document. RFC8292 is an extension that can be used with the mechanism defined in
> RFC8030, but it cannot be applied to any PNS on the fly. A PNS would have to
> explicitly support it.
> 
>>Also, it says
>>
> I can add a reference. However, while many of the security considerations in
> RFC8030 probably apply to any PNS, they are still written for a specific PNS.

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.

Thanks,

Scott

---

From: Ben Campbell <[email-masked]>
Date: Fri, 4 Jan 2019 17:15:43 -0600

(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 <[email-masked]> wrote:
> 

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.

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

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Jan 2019 18:15:05 +0000

Hi Scott,

…

>I don't want to go through the whole document again, and I don't want to make too big a
>deal of this (the RFC editor has final say) but here are a few examples of things I had to read
>more than once to understand:
>

Ok, I will look into this and see if it could be made more clear.

…

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

RFC 8030 defines an "IETF PNS". The Apple PNS and Android PNS are proprietary (that existed before 8030 was even published).

Also, it is important that the security considerations of 8030 mostly apply to the PNS itself. The push draft does not define a PNS (eventhough it does make some assumptions on how a PNS using the push mechanism work), but a mechanism to transport PNS-related information over SIP, so the scope is slightly different.

Regards,

Christer

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Jan 2019 12:21:19 -0600

[with the caveat that I've only read the security considerations and not
the whole document, yet...]

> 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 t…

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)

> 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…

That seems like a pretty nice way to say it.

-Benjamin

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 5 Jan 2019 18:42:05 +0000

Hi,

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

I'd be happy to add that.

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Jan 2019 13:19:27 -0600

> On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

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.

> That seems like a pretty nice way to say it.

Would that be sufficient to resolve your concern above?

Thanks!

Ben.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 5 Jan 2019 13:33:46 -0600

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

-Benjamin

---

From: Ben Campbell <[email-masked]>
Date: Sat, 5 Jan 2019 14:00:44 -0600

> On Jan 5, 2019, at 1:33 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

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.

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Jan 2019 16:10:11 +0000

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

As indicated yesterday, I would be happy to add such text.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 6 Jan 2019 12:05:15 -0600

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 6 Jan 2019 20:59:57 +0000

Hi,

Based on the sec-dir comments, I have updated the pull request:

https://github.com/cdh4u/draft-sip-push/pull/31/files

I modified my suggested changes to the security considerations, in order to make everything fit with the existing text.

Ben, I think it would be useful to submit a new version of the draft before the IESG review.

Regards,

Christer

________________________________
From: Benjamin Kaduk <[email-masked]>
Sent: Sunday, January 6, 2019 8:05 PM
To: Christer Holmberg
Cc: Ben Campbell; Scott G. Kelly; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21

-Benjamin