[Home]

Summary:ASTERISK-27284: Status of RFC 3323 and PJSIP
Reporter:dtryba (dtryba)Labels:patch pjsip
Date Opened:2017-09-21 08:47:55Date Closed:2017-10-06 01:54:02
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip_caller_id
Versions:13.14.1 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) ASTERISK-27284.diff
Description:My upstream provider complained that Anonymous calls to our endusers got de-anonymized during transit in our platform. These incoming calls have the headers:
{quote}
From: "Anonymous" <sip:anonymous@anonymous.invalid>
{quote}
and
{quote}
Privacy: id;user;critical
P-Asserted-Identity: "Example" <sip:0123456789@example.org;user=phone>
{quote}
After passing through Asterisk 13.14.x, the Privacy header is removed, PAI is unaffected and From is changed to:
{quote}
From: "Example" <sip:0123456789@example.org;user=phone>
{quote}

All involved pjsip endpoints have send_pai, trust_id_inbound and trust_id_outbound set to yes.

This violates RFC 3233:
{quote}
Privacy-hdr  =  "Privacy" HCOLON priv-value *(";" priv-value)
  priv-value   =   "header" / "session" / "user" / "none" / "critical" / token
{quote}

Where:
{quote}
critical: The user asserts that the privacy services requested for
this message are critical, and that therefore, if these privacy
services cannot be provided by the network, this request should be
rejected.  Criticality cannot be managed appropriately for
responses.
{quote}

But is RFC 3323 still applicable to SIP?
Comments:By: Asterisk Team (asteriskteam) 2017-09-21 08:47:57.649-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Joshua C. Colp (jcolp) 2017-09-21 08:51:56.824-0500

What happens if you set "trust_id_outbound" to no? That option configures whether private details are sent to the endpoint or not.
By: dtryba (dtryba) 2017-09-21 08:54:18.086-0500

The cause of the problem is in res/res_pjsip_caller_id.c:152
{code}
  if (privacy && !pj_stricmp2(&privacy->hvalue, "id")) {
     id->number.presentation = AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED;
     id->name.presentation = AST_PRES_PROHIB_USER_NUMBER_NOT_SCREENED;
  } else {
     id->number.presentation = AST_PRES_ALLOWED_USER_NUMBER_NOT_SCREENED;
     id->name.presentation = AST_PRES_ALLOWED_USER_NUMBER_NOT_SCREENED;
  }
{code}

If the Privacy header isn't exactly "id", any call will be de-anonymized. Might this have to be changed to a pj_stristr construction? Or splitting the value of Privacy on ; and check the parts of it?
By: Joshua C. Colp (jcolp) 2017-09-21 09:00:20.109-0500

Using pj_stristr is probably the easiest option.
By: dtryba (dtryba) 2017-09-21 09:06:41.955-0500

With  "trust_id_outbound" to no:

No Privacy header and "Privacy: id,user,critical" have the same effect that From is de-anonymized and PAI is passed.
With "Privacy: id", From remains anonymous and PAI is stripped.
By: dtryba (dtryba) 2017-09-21 09:12:51.542-0500

BTW the dialplan is a simple:
exten => _0.,1,Dial(PJSIP/{$EXTEN}@outgoing)

With trust_id_outbound = yes:

{noformat}
<--- Received SIP request (965 bytes) from UDP:172.16.0.2:5060 --->
INVITE sip:0402938661@10.0.4.217 SIP/2.0
Via: SIP/2.0/UDP 172.16.0.2:5060;branch=z9hG4bK20f3917a
Max-Forwards: 70
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as299f4b90
To: <sip:0402938661@10.0.4.217>
Contact: <sip:anonymous@172.16.0.2:5060>
Call-ID: 65d2fade6ad8ee6b32bcfb6c07f6cbf2@172.16.0.2:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 11.13.1~dfsg-2+deb8u2
Date: Thu, 21 Sep 2017 14:09:31 GMT
Session-Expires: 1800
Min-SE: 90
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Privacy: id;user;critical
P-Asserted-Identity: "Example" <sip:0123456789@example.org>
Content-Type: application/sdp
Content-Length: 246

   -- Executing [0402938661@outgoing:1] Dial("PJSIP/sbcs-00000054", "PJSIP/0402938661@pathfinderpocosnl") in new stack
<--- Transmitting SIP request (1122 bytes) to UDP:109.235.32.45:5060 --->
INVITE sip:0402938661@109.235.32.45;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.0.4.217:5060;rport;branch=z9hG4bKPj59a996da-8edd-4ff7-8cfb-5a71adf9f5aa
From: "Example" <sip:0123456789@10.0.4.217;user=phone>;tag=237a8de0-c01e-467e-aa7e-ae84f25ed0b6
To: <sip:0402938661@109.235.32.45;user=phone>
Contact: <sip:unknown@10.0.4.217:5060>
Call-ID: 580e1db1-20fa-4b8b-a7f1-0c4d034a1849
CSeq: 2844 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
P-Asserted-Identity: "Example" <sip:0123456789@10.0.4.217;user=phone>
Max-Forwards: 70
User-Agent: Asterisk PBX 13.14.1~dfsg-2+deb9u1
Content-Type: application/sdp
Content-Length:   336
{noformat}
By: dtryba (dtryba) 2017-09-26 06:52:17.657-0500

Looking into the RFC 3323/3325 I somehow managed to misread 3325 into thinking it wasn't related to 3323. But https://tools.ietf.org/html/rfc3325#section-9.3 clearly states

{quote}
This specification adds a new privacy type ("priv-value") to the  Privacy header, defined in https://tools.ietf.org/html/rfc3325#ref-2
{quote}

To the handling of the Privacy header in Asterisk in both chan_sip and pjsip  is clearly lacking any support for RFC 3323. Both channel drivers only respect the "id" value of Privacy. Any combination of "id", "header", "session", "user" and "critical" should result in anonymousness. IMHO this means privacy requests are being violated and this should be a critical bug.

Attached is a patch (against 13.14.1) assuming that if the Privacy header isn't exactly "none", privacy is requested for pjsip (tested below, exact patch for trunk) and chan_sip (untested, trunk has an offset for this patch).

What is missing in this fix is that the Privacy header on the incoming call leg is retained on the outgoing call leg instead of just simply adding "Privacy: id" when privacy is requested (haven't looked at finding out how to do that).

pjsip.conf for all endpoints:
send_pai  = yes
trust_id_inbound = yes
trust_id_outbound = yes
contact_user=unknown

Request:
{quote}
<--- Received SIP request (936 bytes) from UDP:172.16.0.2:5060 --->
INVITE sip:0402938661@10.0.4.217 SIP/2.0
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=as7fcb78fa
To: <sip:0402938661@10.0.4.217>
Contact: <sip:anonymous@172.16.0.2:5060>
P-Asserted-Identity: "Example" <sip:0123456789@example.org>
{quote}

Relayed INVITE:
without Privacy header:
{quote}
<--- Transmitting SIP request (1125 bytes) to UDP:109.235.32.45:5060 --->
INVITE sip:0402938661@109.235.32.45;user=phone SIP/2.0
From: "Example" <sip:0123456789@10.0.4.217;user=phone>;tag=a440cfd8-96ef-4959-891a-b557b20cc4db
To: <sip:0402938661@109.235.32.45;user=phone>
Contact: <sip:unknown@10.0.4.217:5060>
P-Asserted-Identity: "Example" <sip:0123456789@10.0.4.217;user=phone>
{quote}

Privacy: none
{quote}
<--- Transmitting SIP request (1124 bytes) to UDP:109.235.32.45:5060 --->
INVITE sip:0402938661@109.235.32.45;user=phone SIP/2.0
From: "Example" <sip:0123456789@10.0.4.217;user=phone>;tag=3ac83cc5-2e44-4765-8731-998811ee2c51
To: <sip:0402938661@109.235.32.45;user=phone>
Contact: <sip:unknown@10.0.4.217:5060>
P-Asserted-Identity: "Example" <sip:0123456789@10.0.4.217;user=phone>
{quote}

Privacy: id
{quote}
<--- Transmitting SIP request (1145 bytes) to UDP:109.235.32.45:5060 --->
INVITE sip:0402938661@109.235.32.45;user=phone SIP/2.0
From: "Anonymous" <sip:anonymous@anonymous.invalid;user=phone>;tag=d4bcf587-48ce-4e8f-9f8d-f695ebd6c4a5
To: <sip:0402938661@109.235.32.45;user=phone>
Contact: <sip:unknown@10.0.4.217:5060>
Privacy: id
P-Asserted-Identity: "Example" <sip:0123456789@10.0.4.217;user=phone>
{quote}

Privacy: id;user;critical
{quote}
<--- Transmitting SIP request (1144 bytes) to UDP:109.235.32.45:5060 --->
INVITE sip:0402938661@109.235.32.45;user=phone SIP/2.0
From: "Anonymous" <sip:anonymous@anonymous.invalid;user=phone>;tag=8b27dba7-9734-432b-bab0-179287ae2934
To: <sip:0402938661@109.235.32.45;user=phone>
Contact: <sip:unknown@10.0.4.217:5060>
Privacy: id
P-Asserted-Identity: "Example" <sip:0123456789@10.0.4.217;user=phone>
{quote}
By: Friendly Automation (friendly-automation) 2017-10-06 01:54:03.641-0500

Change 6642 merged by Jenkins2:
res_pjsip_caller_id chan_sip: Comply to RFC 3323 values for privacy

[https://gerrit.asterisk.org/6642|https://gerrit.asterisk.org/6642]
By: Friendly Automation (friendly-automation) 2017-10-06 01:58:38.205-0500

Change 6650 merged by Joshua Colp:
res_pjsip_caller_id chan_sip: Comply to RFC 3323 values for privacy

[https://gerrit.asterisk.org/6650|https://gerrit.asterisk.org/6650]
By: Friendly Automation (friendly-automation) 2017-10-06 02:04:40.383-0500

Change 6651 merged by Joshua Colp:
res_pjsip_caller_id chan_sip: Comply to RFC 3323 values for privacy

[https://gerrit.asterisk.org/6651|https://gerrit.asterisk.org/6651]
By: Friendly Automation (friendly-automation) 2017-10-06 03:42:26.370-0500

Change 6652 merged by George Joseph:
res_pjsip_caller_id chan_sip: Comply to RFC 3323 values for privacy

[https://gerrit.asterisk.org/6652|https://gerrit.asterisk.org/6652]