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

"Scott G. Kelly" <scott@hyperthought.com> Fri, 04 January 2019 19:46 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03795130E8E for <secdir@ietfa.amsl.com>; Fri, 4 Jan 2019 11:46:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFU9vhn_y_GE for <secdir@ietfa.amsl.com>; Fri, 4 Jan 2019 11:46:27 -0800 (PST)
Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 14A01130E8F for <secdir@ietf.org>; Fri, 4 Jan 2019 11:46:26 -0800 (PST)
Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CF4C756EC; Fri, 4 Jan 2019 14:46:24 -0500 (EST)
Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B07E256F0; Fri, 4 Jan 2019 14:46:24 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app28.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Fri, 04 Jan 2019 14:46:24 -0500
Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app28.wa-webapps.iad3a (Postfix) with ESMTP id 9F06621A61; Fri, 4 Jan 2019 14:46:24 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 4 Jan 2019 11:46:24 -0800 (PST)
X-Auth-ID: scott@hyperthought.com
Date: Fri, 04 Jan 2019 11:46:24 -0800
From: "Scott G. Kelly" <scott@hyperthought.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-sipcore-sip-push.all@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
In-Reply-To: <DB7PR07MB56286B4A2702A5FF1915D1D6938D0@DB7PR07MB5628.eurprd07.prod.outlook.c om>
References: <1546285539.44113084@apps.rackspace.com> <DB7PR07MB56286B4A2702A5FF1915D1D6938D0@DB7PR07MB5628.eurprd07.prod.outloo k.com>
Message-ID: <1546631184.64914945@apps.rackspace.com>
X-Mailer: webmail/15.4.8-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/5eMW9AtCh70HEu5Xb_W1whHK0M0>
Subject: Re: [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: Fri, 04 Jan 2019 19:46:29 -0000

Hi Christer,

On Thursday, January 3, 2019 3:29am, "Christer Holmberg" <christer.holmberg@ericsson.com> said:

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

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


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