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

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 31 Jul 2018 20:02:20 +0000

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