Skip to main content

Last Call Review of draft-ietf-sipcore-sip-push-21

Request Review of draft-ietf-sipcore-sip-push
Requested revision No specific revision (document currently at 29)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-12-21
Requested 2018-12-07
Authors Christer Holmberg , Michael Arnold
I-D last updated 2019-01-03
Completed reviews Secdir Last Call review of -21 by Scott G. Kelly (diff)
Genart Last Call review of -21 by Stewart Bryant (diff)
Assignment Reviewer Scott G. Kelly
State Completed
Request Last Call review on draft-ietf-sipcore-sip-push by Security Area Directorate Assigned
Reviewed revision 21 (document currently at 29)
Result Has issues
Completed 2019-01-03
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

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

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.