Subject: Re: [sipcore] draft-burger-sipcore-rejected-01 / Security Considerations

From: Eric Burger <[email-masked]>
Date: Thu, 2 Aug 2018 15:16:27 -0400

For the first issue, my bad - the smurf attack will not be via Contact, but via SDP. Either way, the point is to not trust untrusted INVITEs. Good catch.

For the second issue, I’m not sure how to protect against it, other than to say, “Be careful who you try to call because they may try to hack you back in a 608.”

Any ideas?

> On Jul 31, 2018, at 4:02 PM, Asveren, Tolga <[email-masked]> wrote:
> 
> A few comments regarding draft-burger-sipcore-rejected-01 from security perspective:
> 
> i-  "6. Security Considerations"
> Another risk is for an attacker to purposely not include the sip.608
>   feature capability in a flood of INVITE requests, direct those
>   requests to stateless proxies, and direct the Contact header to a
>   victim device.  Because the mechanism described here can result in an
>   audio file being sent to the target of the Contact header, an
>   attacker could use the mechanism described by this document as an
>   amplification attack, given a SIP INVITE can be under 1 kilobyte and
>   an audio file can be hundreds of kilobytes.
> 
> 
> I am not sure whether this would be an issue. For most cases, session negotiation pertaining to announcement would complete within the initial INVITE transaction and therefor Contact wouldn't come into play as it is used for new requests but not for responses for the initial INVITE. And if session negotiation for the announcement involves a request from the intermediary, e.g. UPDATE or reINVITE after the dialog is established, the request should be dropped by the recipient (the entity specified in Contact for INVITE) as it has a to-tag and a corresponding dialog context does not exist. Or maybe I am missing the intended scenario here?
> 
> 
> ii- A malicious entity can generate a 608 response with a vCard pointing to a malicious agent. When, for example, the recipient of 608 dials the TEL information in the vCard he may provide private information by assuming that he is contacting a legitimate regulatory department. I think adding some text to mandate use of certificates for vCards and that UE needs to verify them is justified. There still would be an issue if the UE is unable to display the vCard and/or the certificate derived organization and for the announcement case though. It could be an idea the contact information (vCard or announcement) is provided by a new call where originator is STIR verified but then that wouldn't help if UE is not STIR-aware.
> 
> Thanks,
> Tolga
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 3 Aug 2018 19:50:23 +0000

Sure, SDP smurf attack would be possible but please note that this is not due to some mechanism introduced by this draft. The same can be done with a vanilla call sent to an announcement playing service, e.g. voice/digit based bank service which first plays an announcement for menu items and usually repeats it several times before terminating the call in case there is no input.

I don’t think end users would read this draft by and large (except the lucky few  involved in IETF) so would a “Be careful who you try to call because they may try to hack you back in a 608.” warning statement really make any difference in practice?  

And, no, I can’t think of a silver bullet for this one. Just a few ideas, which may help better the situation:
i- Announcements, if no 608 support is indicated in INVITE, can be played in a separate call. If endpoint supports STIR/SHAKEN but not 608, this at least would provide information about the entity providing the contact information for further action.
ii- Originating network gets an out-of-band notification about rejection and then uses SMS/IM etc... to notify the enduser. 

Thanks,
Tolga

> -----Original Message-----
> From: Asveren, Tolga
> Sent: Friday, August 3, 2018 4:15 AM
> To: Asveren, Tolga <[email-masked]>
> Subject: RE: [sipcore] draft-burger-sipcore-rejected-01 / Security
> Considerations
> 
> For the first issue, my bad - the smurf attack will not be via Contact, but via
> SDP. Either way, the point is to not trust untrusted INVITEs. Good catch.
> 
> For the second issue, I’m not sure how to protect against it, other than to
> say, “Be careful who you try to call because they may try to hack you back in a
> 608.”
> 
> Any ideas?
> 
> 
> > On Jul 31, 2018, at 4:02 PM, Asveren, Tolga <[email-masked]>; wrote:
> >
> > I am not sure whether this would be an issue. For most cases, session
> negotiation pertaining to announcement would complete within the initial
> INVITE transaction and therefor Contact wouldn't come into play as it is used
> for new requests but not for responses for the initial INVITE. And if session
> negotiation for the announcement involves a request from the intermediary,
> e.g. UPDATE or reINVITE after the dialog is established, the request should
> be dropped by the recipient (the entity specified in Contact for INVITE) as it
> has a to-tag and a corresponding dialog context does not exist. Or maybe I
> am missing the intended scenario here?
> >
> >
> > ii- A malicious entity can generate a 608 response with a vCard pointing to a
> malicious agent. When, for example, the recipient of 608 dials the TEL
> information in the vCard he may provide private information by assuming
> that he is contacting a legitimate regulatory department. I think adding some
> text to mandate use of certificates for vCards and that UE needs to verify
> them is justified. There still would be an issue if the UE is unable to display
> the vCard and/or the certificate derived organization and for the
> announcement case though. It could be an idea the contact information
> (vCard or announcement) is provided by a new call where originator is STIR
> verified but then that wouldn't help if UE is not STIR-aware.
> >
> > Thanks,
> > Tolga
> >