From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Scott G. Kelly" <scott@hyperthought.com>, "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>
Thread-Topic: secdir review of draft-ietf-sipcore-sip-push-21
Thread-Index: AQHUoUFwpb8nIR8T3kKT3FjKoKE4faWdaLFK
Date: Thu, 3 Jan 2019 11:29:42 +0000
Message-ID: <DB7PR07MB56286B4A2702A5FF1915D1D6938D0@DB7PR07MB5628.eurprd07.prod.outlook.com>
References: <1546285539.44113084@apps.rackspace.com>
In-Reply-To: <1546285539.44113084@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: ericsson.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
 boundary="_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7674955c-d787-451d-4ecf-08d6716ec1cb
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2019 11:29:42.9921 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4585
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUgUYRjHe2dm13Fz43W8nraEWuqDq+tV4SIaRgTSAdsXUVm0NccjdbUZ
 tbQQsSjUD62poYuwmkugZK33kYiZlUeUeXTYQaYYq1G6JZKK5DgWfvv9/8//eXn+8NIk0yxR
 0MmGTJYz6FOVUhlVGdmepVbZ1Tr/kmKF5nvbINJUrJWQmqUWI9Is1ExRYVR4R8cQFW6x/CG0
 RLQsJJ5NTc5mOb+j52RJhQ1eGf0nLv8s6SHz0bXgIuRIAz4M41UFkiIkoxncj+DGLysSxRKC
 fKuV+C/sd62kKGoJGCq0SQVBYSMJj758lAiPMbiEgJqx3WJqCsHQi88bKZqWYg0Ur3sLvise
 QTBQW7bpu+AQaBsIEnZdcShYi5akIgdCWaeJFJjCB+Dp4hgSWI510G60I2GV2Th8bpYSbEd8
 BMwN9ZsnIOwOy0P3CYFJ7AGTM2ZC7InB0v2KFNkNbNPrEpH3wcRwq1RkTxg1F2/WB1zgAHUf
 upA4UMNCefnW8hmYHBwmxdBGl+KqOUocqKDpeu/WQgrYW6e3Qq9JeFAw5yBcDXgvfOqJEP1F
 CdwZN1JG5Gfadq3I6TDYXEeaNks7w2DlDCX6vvCuvEwqsjfcq5knRVZDxXoftd2vRg71yI1n
 +bi0xMBAX5ZLPs/z6QZfA5vZhDa+0uOWVf8OZPt2rA9hGimd5BOLah0j0WfzOWl9CGhS6Sp3
 5310jDxen5PLcumxXFYqy/ehPTSl9JCvMc46BifqM9kUls1guX9TgnZU5COFlg485C4/Xn0w
 76Jvc1CMHeJWRp/8YKaQdodBannusZyV4HlzMjZh/FLim5fzu/K7GlZrg9fuPrPVlpZqvX6f
 Mu8/OadOaJTaI51ur9yKino7e9qoujqWx/VyjRfeLz38yi+aOg3zodGuLnR5WGZM2E6yO9Qc
 cSVANjKc63NWSfFJ+gAVyfH6v0HFw0tGAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/069fgTgZdVI9vO0ZU1f4vPHguSo>
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: Thu, 03 Jan 2019 11:29:51 -0000

--_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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 understan=
d. 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.

>For security considerations, there are 3 entities involved in the communic=
ations 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 P=
RID to the PNS along with a message for the UA, and the PNS uses the PRID t=
o >route the message to the right UA.

Correct.

Note, though, that the "message" is only a push notification in order to wa=
ke 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 i=
nteractions, it says "The mechanisms >for authorizing and authenticating th=
e 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 PN=
S specific.

>For application server (SIP proxy) to PNS interactions, it mentions the fa=
ct 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 >me=
chanism 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 d=
ocument. RFC8292 is an extension that can be used with the mechanism define=
d in RFC8030, but it cannot be applied to any PNS on the fly. A PNS would h=
ave 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 cho=
oses a proprietary
>scheme with weak crypto and claims that is "properly secured", have they m=
et this requirement?

I could say something like: "is secured using some other mechanism that pro=
vides strong crypto properties".

>Finally, I think RFC8030 has a good description of the security considerat=
ions for this use case, and
>should be referenced here.

I can add a reference. However, while many of the security considerations i=
n RFC8030 probably apply to any PNS, they are still written for a specific =
PNS.

Regards,

Christesr


--_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">Hi Scott,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">Thank You for the review! Please =
see inline.</p>
<p style=3D"margin-top:0;margin-bottom:0"><font size=3D"2"><span style=3D"f=
ont-size:11pt;"><br>
</span></font></p>
<div style=3D"color: rgb(0, 0, 0);">
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">&gt;The summary of the review is ready with issues=
.<br>
&gt;<br>
&gt;The document describes how to enable a push notification service (PNS) =
to&nbsp;</div>
<div class=3D"PlainText">&gt;wake a suspended SIP user agent.<br>
&gt;<br>
&gt;Due to the writing style, I found the document very difficult to unders=
tand. Maybe&nbsp;</div>
<div class=3D"PlainText">&gt;the RFC editor can help with this, but it migh=
t be better if someone from the working&nbsp;</div>
<div class=3D"PlainText">&gt;group helped out with word-smithing.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">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.<br>
<br>
&gt;For security considerations, there are 3 entities involved in the commu=
nications defined by this document: the &gt;user agent (UA), the PNS server=
, and the application server (in this case, a SIP proxy). The basic idea is=
 that the &gt;UA registers with the PNS,
 obtaining a Push Resource ID (PRID). The UA provides the PRID to the SIP p=
roxy, and &gt;then the SIP proxy presents the PRID to the PNS along with a =
message for the UA, and the PNS uses the PRID to &gt;route the message to t=
he right UA.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">Correct.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">Note, though, that the &quot;message&quot; is only=
 a push notification in order to wake up the UA. The actual SIP message (th=
at triggered the push notification) will then be routed to the UA using nor=
mal SIP procedures.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">&gt;The security considerations section mostly pun=
ts. With respect to UA-PNS interactions, it says &quot;The mechanisms &gt;f=
or authorizing and authenticating the users are PNS-specific, and are outsi=
de the scope of this document.&quot; It &gt;says nothing
 about how the UA authenticates the PNS.&nbsp;</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">The UA-PNS interactions, including how the UA auth=
enticates the PNS, are PNS specific.<br>
<br>
&gt;For application server (SIP proxy) to PNS interactions, it mentions the=
 fact that a PNS may requires some sort of &gt;authz/authn for the SIP prox=
y, but it gives no requirements/recommendations here. It later mentions a J=
WT &gt;mechanism for this purposes described
 in RFC8292, but again, no requirement, no recommendation.<br>
<br>
</div>
<div class=3D"PlainText">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.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">&gt;Also, it says<br>
&gt;<br>
&nbsp; &gt; Operators MUST ensure that the SIP signalling is properly secur=
ed,<br>
&nbsp;&nbsp; &gt; e.g., using encryption, from malicious middlemen.&nbsp; T=
LS MUST be used,<br>
&nbsp;&nbsp; &gt; unless the operators know that the signalling is secured =
using some<br>
&nbsp;&nbsp; &gt; other mechanism.<br>
&gt;<br>
&gt;I don't think there is a clear requirement stated here. If an operator =
chooses a proprietary&nbsp;</div>
<div class=3D"PlainText">&gt;scheme with weak crypto and claims that is &qu=
ot;properly secured&quot;, have they met this requirement?&nbsp;</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">I could say something like: &quot;is secured using=
 some other mechanism that provides strong crypto properties&quot;.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">&gt;Finally, I think RFC8030 has a good descriptio=
n of the security considerations for this use case, and&nbsp;</div>
<div class=3D"PlainText">&gt;should be referenced here.</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">I can add a reference. However, while many of the =
security considerations in RFC8030 probably apply to any PNS, they are stil=
l written for a specific PNS.<br>
<br>
</div>
<div class=3D"PlainText">Regards,</div>
<div class=3D"PlainText"><br>
</div>
<div class=3D"PlainText">Christesr<br>
<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>

--_000_DB7PR07MB56286B4A2702A5FF1915D1D6938D0DB7PR07MB5628eurp_--