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

"Scott G. Kelly" <scott@hyperthought.com> Mon, 31 December 2018 19:45 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 98977130EF3 for <secdir@ietfa.amsl.com>; Mon, 31 Dec 2018 11:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E_jlPGDJIDXL for <secdir@ietfa.amsl.com>; Mon, 31 Dec 2018 11:45:40 -0800 (PST)
Received: from smtp122.iad3a.emailsrvr.com (smtp122.iad3a.emailsrvr.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5A31130E4B for <secdir@ietf.org>; Mon, 31 Dec 2018 11:45:40 -0800 (PST)
Received: from smtp24.relay.iad3a.emailsrvr.com (localhost []) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A4A4924A71; Mon, 31 Dec 2018 14:45:39 -0500 (EST)
Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net []) by smtp24.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8E64B21170; Mon, 31 Dec 2018 14:45:39 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app46.wa-webapps.iad3a (relay-webapps.rsapps.net []) by (trex/5.7.12); Mon, 31 Dec 2018 14:45:39 -0500
Received: from hyperthought.com (localhost.localdomain []) by app46.wa-webapps.iad3a (Postfix) with ESMTP id 6C5804008C; Mon, 31 Dec 2018 14:45:39 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Mon, 31 Dec 2018 11:45:39 -0800 (PST)
X-Auth-ID: scott@hyperthought.com
Date: Mon, 31 Dec 2018 11:45:39 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-sipcore-sip-push.all@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1546285539.44113084@apps.rackspace.com>
X-Mailer: webmail/15.4.8-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mDNPSc04mZ7aJoieL6SAC9aHtQE>
Subject: [secdir] secdir review of draft-ietf-sipcore-sip-push-21
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Dec 2018 19:45:45 -0000

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.