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,


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]<mailto:[e-mail]> and [e-mail]<mailto:[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]<mailto:[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.

Such registrar/endpoint would not even be SIP compliant.

But, IF it happens, the UA associated with PRIDb will receive a push notification and send a REGISTER. But, since the REGISTER contact will not match the R-URI of the SIP request to be forwarded, the SIP request will not be forwarded by the proxy (eventually there will be a timeout)

---

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?

E.g., if the UA has changed its IP address and/or port.


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?

I suggested modified text, that only talks about the case when there is a match. In other cases, when there is no match, there will be a timeout.

---

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.

Ok. I suggest to add:

"Since the PURR value will be transported to the remote peer, the value MUST be generated..."

---

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.

I can change "middleman" to "endpoint".

Regards,

Christer