Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - The DISCUSS issues

[Eric Rescorla <[e-mail]>]

On Mon, Jan 7, 2019 at 2:11 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
> Thank You for the review! In this reply I'll try to address the DISCUSS
> issues. The COMMENT issues will be addressed in a separate reply.
>
> DETAIL
> S 5.3.2.
> >>      request) addressed towards a SIP UA, if the Request-URI of the
> >>      request contains a pn-provider, a pn-prid and a pn-param (if
> required
> >>      for the specific PNS provider) SIP URI parameter, the proxy
> requests
> >>      a push notification towards the UA, using the PRID included in the
> >>      pn-prid SIP URI parameter and the PNS identified by the pn-provider
> >>      SIP URI parameter.
> >
> >Maybe I'm missing something, but this seems like it leaves open the
> >possibility for the PRID to not match the rest of the URI. E.g.,
> >suppose that [e-mail] and [e-mail] both register with the
> >same proxy/registrar pair with PRIDa and PRIDb respectively. What
> >stops the registrar from generating (or forwarding) a call to
> >[e-mail], PRIDb? And what happens if that happens?
>
> Since no [e-mail]:PRIDb binding has been registered, the registrar
> will not generate such URI.
>

No conformant registrar will. But what about a nonconformant one? Or
another endpoint.

---
>
> S 5.3.2.
> >>      also present (and has not expired) in the REGISTER response, the
> >>      proxy can forward the SIP request towards the UA, using normal SIP
> >>      procedures.  If the contact of the REGISTER request does not match
> >>      the Request-URI of the SIP request to be forwarded, or if the
> contact
> >>      was not present in the REGISTER response, the proxy MUST reject the
> >>      SIP request with a 404 (Not Found) response.  This can happen if
> the
> >
> >How does this happen? I.e., how does the the REGISTER get correlated
> >with the SIP request to be forwarded in order to execute this
> >requirement?
>
> There could be cases where e.g. the PRID values match, but the rest of the
> contact don't.
>

Such as?


But, I don't think that is relevant. What matters is that the contacts DO
> match, AND that the contact is present in the REGISTER response. The rest
> will be handled by the timeout procedures.
>

But *this* text requires you to behave in a certain way in case of
mismatch. When will this be executed?

>
> S 6.1.
> >>      and be able to find and retrieve that information when it receives
> a
> >>      mid-dialog request.  This section defines such mechanism.  The UA
> and
> >>      proxy procedures in this section are applied in addition to the
> >>      generic procedures defined in this specification.
> >>
> >>   6.1.  SIP UA Behavior
> >
> >This section needs some kind of diagram that explains what the
> >mechanism is. I've read it a bunch of times, and I still don't
> >understand it.
>
> I think it would more or less be a copy of the diagram in Section 1. I
> could either reference, or copy/paste that diagram.
>
> ---
>
> S 6.2.1.
> >>      generated key as the value to the associated 2xx REGISTER response.
> >>
> >>      The PURR value MUST be generated in such a way so that it cannot be
> >>      used to retrieve information about the user or associate it with
> >>      registrations.  It can be generated e.g., by utilizing a
> >>      cryptographically secure random function.
> >
> >This seems to weak. I assume you also don't want it to be possible to
> >determine that two PURRs correspond to the same user. Also who must be
> >able to use it in this way. Presumably the proxy can?
> >
> >Why is this not a requirement for say PRID?
>
> The PURR value will reach the remote user. The PRID will only reach the
> registrar.
>

You need to say that.





S 13.
>>      specification.  Web push permits the sending of a push message
>>      without a payload without encryption.
>>
>>   13.  Security Considerations
>>
>>      Different mechanisms exist for authenticating and authorizing
devices
>
>You need to discuss the security implications of knowledge of the push
>parameters (principally PRID). What happens if an attacker learns
>them?

>
> Based on the sec-dir review, I did some modifications/additions to the
> security considerations. They can be seen in the following pull request:
>
> https://github.com/cdh4u/draft-sip-push/pull/31
>
>
> Regarding your comment, I have tried to address that with the following
> suggested text:
>
>             "Typically, the PNS requires the SIP proxy requesting push
> notifications to be
>             authenticated and authorized by the PNS. In some cases the PNS
> also require
>             the SIP application (or the SIP application developer) to be
> identified in order for the
>             application to request push notifications. Unless the PNS
> authenticates and authorizes the PNS,
>             a malicious middleman that managed to get access to the
> parameters transported in the SIP signalling
>             might be able to request push notifications towards a UA.
> Which such push notifications will not
>             have any security related impacts, they will impact the
> battery life of the UA and trigger
>             unnecessary SIP traffic."
>

Why "middleman" as opposed to any endpoint.

>
> Regards,
>
> Christer
>
>
>
>