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

[Christer Holmberg <[e-mail]>]

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.

---

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.

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.

So, I think something like the following would be enough:

   "If the contact of the REGISTER request was not present in the
     REGISTER response, the proxy MUST reject the SIP request with a
     404 (Not Found) response."

In addition, we could add a note below the timeout paragraph:

   "If the proxy does not receive the REGISTER request from the UA within
   a given time after the proxy has requested the push notification, the
   proxy MUST reject the request with a 480 (Temporarily Unavailable)
   response.  The time value is set based on local policy.

   NOTE: In case a UA sends a binding-refresh REGISTER request that does not contain the
   previously registered contact at the same time the registrar forwards a SIP request
   towards a UA using the previously registered contact in the Request-URI, the proxy
   will not be able to match the contact with the Request-URI. This will trigger a timeout
   response.

---

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.

---

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

Regards,

Christer