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

Ben Campbell <> Sat, 05 January 2019 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6AA8130E5F; Sat, 5 Jan 2019 11:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id apH3seKQLyoG; Sat, 5 Jan 2019 11:19:37 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2BA1130E36; Sat, 5 Jan 2019 11:19:36 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x05JJRAR016685 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Jan 2019 13:19:29 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1546715970; bh=/sDvZLXsLeDqc7GNWvIsX9y5clkwNVTn0hBaOZT2MMU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=ITYU3OAR02LrfOoiAiesBtoXaYAJwHNmss9K4uirZnc08Srp9omimmiYcajpCrn2k uRARVU4lcSVHsEx1qx/JQdgxJ49p1WEEunsg10NrOIkqqnvb7cpihcA5OkSf68jhBb b8E6I2RZW1ISb978Xr+1ovzfnhg5Ja61cPk4divU=
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_0582A06C-09FE-4544-8602-DA7B23F1FD95"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sat, 5 Jan 2019 13:19:27 -0600
In-Reply-To: <>
Cc: "Scott G. Kelly" <>, "" <>, "" <>, "" <>, Christer Holmberg <>
To: Benjamin Kaduk <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-sipcore-sip-push-21
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Jan 2019 19:19:40 -0000

> On Jan 5, 2019, at 12:21 PM, Benjamin Kaduk <> wrote:
> [with the caveat that I've only read the security considerations and not
> the whole document, yet...]
> On Fri, Jan 04, 2019 at 05:15:43PM -0600, Ben Campbell wrote:
>> (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 <> wrote:
>>> 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.
>> 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.
> 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)

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.

>> 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.”
> That seems like a pretty nice way to say it.

Would that be sufficient to resolve your concern above?