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

["Scott G. Kelly" <[e-mail]>]

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

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.

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.

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.

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? 

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