Verstat Related Best Practices Mark Desterdick Verizon IP-NNI Task Force May 2, 2018

Topics Format Granularity Legitimate Privacy P-Asserted-ID for SIP and tel URIs Various SIP methods Granularity Terminating Attestation Level Identification to terminating UA or CVT Legitimate Privacy CLIP/CLIR This document offers several proposals for consideration in the IPNNI and other standards bodies to be included in future standards or best practices documents, as appropriate.

P-Asserted-ID: SIP URI Format in P-Asserted_Identity (PAI) using a SIP URI - placement of verstat before the @ sign sip:+358-555-1234567;postd=pp22;verstat=TN-Validation-Passed@foo.com;user=phone  This is derived from the syntax for verstat in the P-asserted-id in Tel-URI format as defined in 3GPP TS24.229 section 7.2A.20. Reasoning: tel:+358-555-1234567;postd=pp22;verstat=TN-Validation-Passed verstat is a TEL URI parameter Parameters are associated with a TEL URI per the syntax specified in RFC-3966 Parameters are associated with a SIP or SIPS URI per the syntax specified in RFC-3261 TEL URIs are mapped to SIP URIs as specified in RFC-3261 Format: P-Asserted-ID: SIP URI Based on the following analysis, the format shown below for verstat in P-Asserted_Identity (PAI) using a SIP URI is correct with the placement of verstat before the @ sign: sip:+358-555-1234567;postd=pp22;verstat=TN-Validation-Passed@foo.com;user=phone   The above is derived from the syntax for verstat in the P-asserted-id in Tel-URI format as defined in 3GPP TS24.229 section 7.2A.20, and using the below reasoning and references. tel:+358-555-1234567;postd=pp22;verstat=TN-Validation-Passed Assertion:  verstat is a TEL URI parameter Explanation: “verstat” is described as a TEL URI in 3GPP TS 24.229 section 7.2A.20.  It is registered as such with IANA.  It is NOT registered as a SIP or SIPS URI parameter.  24.229 indicates that verstat may be used in the From and P-Asserted-Identity headers containing “a tel URI or a SIP URI with the user=phone parameter”. References: https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1055 https://www.iana.org/assignments/tel-uri-parameters/tel-uri-parameters.xhtml https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-11 Parameters are associated with a TEL URI per the syntax specified in RFC-3966 Explanation: the format is basically  tel: <digits> [; <parameter> = <value>]* Reference: https://tools.ietf.org/html/rfc3966 Parameters are associated with a SIP or SIPS URI per the syntax specified in RFC-3261 Explanation:  the format is basically sip:user:password@host:port;uri-parameters?headers.  As noted in point 1 above, however, “verstat” is not registered as a SIP or SIPS URI parameter.  Therefore this syntax cannot be used to incorporate a “verstat” parameter into a SIP or SIPS URI.  Reference: https://tools.ietf.org/html/rfc3261#section-19.1.1 TEL URIs are mapped to SIP URIs as specified in RFC-3261 Explanation:  the mapping logic is in section 19.1.6, which indicates that “When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI.”.  This syntax can be used to incorporate a “verstat” parameter into a SIP or SIPS URI. Reference: https://tools.ietf.org/html/rfc3261#section-19.1.6

Verstat in Various SIP Methods Proposed verstat syntax in various SIP methods INVITE P-Asserted-Identity OR From: tel:+15617500080;verstat=TN-Validation-Passed P-Asserted-Identity OR From: sip:+15617500080;verstat=TN-Validation-Passed@foo.com;user=phone   SUBSCRIBE Message Body Calling-party: tel:+15617500080;verstat=TN-Validation-Passed Calling-party: sip:+15617500080;verstat=TN-Validation-Passed@foo.com;user=phone NOTIFY Calling-Name: "BUSINESS005"  tel:+15617500080;verstat=TN-Validation-Passed OR Calling-party: "BUSINESS005" sip:+15617500080;verstat=TN-Validation-Passed@foo.com; user=phone MESSAGE Format: Verstat in Various SIP Methods A summary of the proposed verstat syntax in various SIP methods is listed below: INVITE P-Asserted-Identity OR From: tel:+15617500080;verstat=TN-Validation-Passed P-Asserted-Identity OR From: sip:+15617500080;verstat=TN-Validation-Passed@foo.com;user=phone   SUBSCRIBE Message Body Calling-party: tel:+15617500080;verstat=TN-Validation-Passed Calling-party: sip:+15617500080;verstat=TN-Validation-Passed@foo.com;user=phone NOTIFY Calling-Name: "BUSINESS005"  tel:+15617500080;verstat=TN-Validation-Passed OR Calling-party: "BUSINESS005" sip:+15617500080;verstat=TN-Validation-Passed@foo.com; user=phone MESSAGE

Granularity Terminating Attestation Level Identification to terminating UA or CVT Current Values Verstat value STI-VS Description TN-Validation-Passed The number passed the validation TN-Validation-Failed The number failed the validation No-TN-Validation No number validation was performed Tagging and Validation Results Sent to UA or CVT Must Reflect the Attestation Indicator While multiple levels of attestation have been introduced for signing within the STIR/SHAKEN framework, the verstat values resulting from the signature validation or those used in tagging currently have no indication what attestation level was used.  The lack of attestation in what is presented to the UA or CVT within the currently defined verstat values poses a risk to the implementation of STIR/SHAKEN due to unintended consequences of introducing multiple attestation levels with signing, but not reflecting them in validation results. To illustrate, consider a case when the attestation indicator is either B or C for a signed call, and a verstat value of TN-Validation-Passed (as a result of a cryptographically sound signature) is sent by the STI-VS to the invoking network device. The network device then passes this verstat value on to a terminating UA, which interprets the results as the originating number having been authenticated when in fact the signature was only using attestation B or C.  This introduces a gap and undermines the premise of trusting the originating number when in it could have been spoofed, but arriving over some IP interface where attestation B was applied, or a gateway where an attestation C for was applied.  Service providers, CVTs and over the top applications have a need to differentiate the validation based on attestation so that appropriate information is relayed to an end user device or analytics platform based on policy. For example, an attestation B or C may not add appreciable value to an end user display regarding the authenticity of a calling number, but may add value to intermediary service providers or analytics engines during traceback investigations, statistical and reputational analysis or troubleshooting. The following illustrate a few other use cases: An application or service provider may choose to ONLY present validation results to an end user if the attestation was A.  A service provider may choose to only use validations of attestation B and C for traceback, behavioral analytics and non-repudiation. Different messages or displays may be presented terminating to end users based on the combination of the validation status and the attestation level.

Granularity Possible Syntax Augmenting current verstat values with a “-A”, “-B” or “-the C” at the end Verstat value STI-VS Description TN-Validation-Passed The number passed the validation (kept to maintain backwards compatibility with early implementations which are expected to sign with Attestation A) TN-Validation-Passed-A The number passed the validation with Attestation A TN-Validation-Passed-B The number passed the validation with Attestation B TN-Validation-Passed-C The number passed the validation with Attestation C TN-Validation-Failed The number failed the validation (kept to maintain backwards compatibility with early implementations which are expected to sign with Attestation A) TN-Validation-Failed-A The number failed the validation for Attestation A TN-Validation-Failed-B The number failed the validation for Attestation B TN-Validation-Failed-C The number failed the validation for Attestation C No-TN-Validation No number validation was performed Possible Syntax for Augmented verstat Values The following is one proposed syntax which has found some acceptance among a few service providers: Augmenting the current verstat values with a “-A”, “-B” or “-C” at the end   Other possible syntax formats: Current values of verstat are retained and P-Attestation-Indicator Header is included in the response from the STI-VS or in the tag toward the terminating node Changing the current verstat values to “Validation-Y-Passed”, “Validation-Y-Failed” and “No-Y-Validation” where Y is the attestation level A, B or C Defining new verstat values for attestation B and C such as: Attestation B: IP-Validation-Passed, IP-Validation-Failed, No-IP-Validation Attestation C: GW-Validation-Passed, GW-Validation-Failed, No-GW-Validation In the case of tagging, the SP should retain the appropriate attestation level in the verstat value upon delivery to terminating UEs, applications or CVTs. Display Framework and OEM Considerations Display framework recommendations will need to be updated to include attestation levels, and OEM procedures will need to address actions for the cases of failed validation.

Verstat for Anonymous CLIP/CLIR verstat should be signaled to the end user even in cases where Privacy is requested For Caller initiated Privacy, common practice has the originating network/device signaling “Anonymous” in the From header.  The P-Asserted-Identity (PAI) would carry the actual Calling Party number. The originating network would perform SHAKEN Authentication over the PAI, sending the Identity header to the terminating network along with the PAI (with callers TN), From (anonymous) and Privacy headers The terminating network performs verification (using the TN received in the PAI), and populates verstat into the PAI Because of the Privacy indication, the terminating network removes the PAI header prior to sending the call to the UE: Example FROM: sip:anonymous;verstat=TN-Validation-Passed@anonymous.invalid  The following are proposed “Best Practices” with regards to sending verstat to the End User in cases of Private/Anonymous calls: For Caller initiated Privacy, common practice has the originating network/device signaling “Anonymous” in the From header.  The P-Asserted-Identity (PAI) would carry the actual Calling Party number. The originating network would perform SHAKEN Authentication over the PAI, sending the Identity header to the terminating network along with the PAI (with callers TN), From (anonymous) and Privacy headers The terminating network performs verification (using the TN received in the PAI), and populates verstat into the PAI Because of the Privacy indication, the terminating network removes the PAI header prior to sending the call to the UE: If the From header indicates “Anonymous”, the From header should be populated with the verstat received in the PAI If the received From header does not indicate “Anonymous”, but the terminating network anonymizes the From header, the From header should be populated with the verstat received in the PAI If the received From header does not indicate “Anonymous” and the terminating network does not anonymize the From header, the From header should not be populated with the verstat received in the PAI (note: would not expect this case to happen because the originating and/or terminating network(s) must anonymize)   Example: FROM: sip:anonymous;verstat=TN-Validation-Passed@anonymous.invalid

Next Steps Agree on Best Practices with limited focused scopes Priority and timeline for Best Practices