STIR (Secure Telephony Identity Revisited) and SHAKEN (Secure Handling of Asserted information using toKENs) are the frameworks to prevent the completion of illegally spoofed telephony sessions. Call spoofing is when a session originator changes the calling number to hide or change which calling number is shown on the telephony session display. STIR provides the ability within SIP to authenticate caller ID, and SHAKEN defines the end-to-end architecture to implement caller ID authentication using STIR in the telephone network. STIR/SHAKEN uses digital certificates, based on common public key cryptography techniques, to ensure the calling number of a telephony session is secure. Each telephone service provider obtains its digital certificates from a trusted certificate authority. The certificate technology enables verifying that the calling number is accurate and has not been spoofed. Figure E.2.1-1 below depicts the SHAKEN reference architecture as specified in TS 24.229 when using end-to-end SIP signalling.

It is based on IMS architecture. The "application server (AS) for signing" is an HTTP-based application server that performs the function of the authentication service defined in RFC 8224 for originating number identity and in RFC 8946 for diverting number identity. The "AS for verification" is an HTTP-based application server that performs the function of the verification service defined in RFC 8224 and in RFC 8946. Certificate Repository (CR) represents the publicly accessible store for public key certificates. Either the Telephony AS or IBCF in the originating service provider's network invokes the AS for signing which creates a digital signature for the call called a PASSportT (Personal Assertion Token) assigned to a SIP Identity header. The IBCF or Telephony AS in the terminating service provider's network invokes the AS for verification which verifies the digital signature of the call. The AS includes a VERSTAT parameter in the P-Asserted-Identity or From header of the SIP INVITE request, with possible values of TN-Validation-Passed, TN-Validation-Failed or No-TN-Validation. A SIP INVITE request might have one Identity added by an authentication service at the originating administrative domain and then other Identity header fields added by some further intermediaries. The presence of multiple Identity header fields within a SIP INVITE request raises the prospect that a verification service could receive a message containing both valid and invalid Identity header fields. As a guideline, RFC 8224 recommends that only if a verifier determines that all Identity header fields within a message are invalid should the request be considered to have an invalid identity. If at least one Identity header field value is valid and from a trusted source, then relying parties can use that header for authorization decisions regardless of whether other untrusted or invalid Identity headers appear in a request.

Some telecommunication regulation authorities may force CSPs implementing STIR/SHAKEN even for intra-network voice sessions. Figure E.2.2-1 depicts the SHAKEN reference architecture for such scenario when using end-to-end SIP signalling. The Telephony AS is the default approach to provide STIR/SHAKEN capabilities, i.e. is capable of invoking the AS for signing on the originating side and AS for verification on the terminating side.

STIR/SHAKEN could apply to providing protection for textual and multimedia messaging as specified in the IETF draft-ietf-stir-messaging-07 [46]. A PASSporT could be used to securely negotiate a session over which messages will be exchanged; this is applicable for example to the following RCS services: large message mode standalone messaging, 1-to-1 chat and group chat where messages are exchanged using MSRP (Message Session Relay Protocol) after the SIP ssession is established. In these scenarios, usage of STIR/SHAKEN is very similar to that for voice sessions. In sessionless scenarios such as RCS pager mode standalone messaging service, a PASSporT could be generated on a per-message (i.e. SIP MESSAGE) basis with its own built-in message security. An Identity header could be added to any SIP MESSAGE request, but without some extension to the PASSporT claims, the PASSporT would offer no protection to the message content. In IETF draft-ietf-stir-messaging-07 [46], PASSporT provides its own integrity check for message contents as part of its assertions through a new claim which is here defined to provide a hash over message contents. A new "msg" PASSporT Type is defined for that purpose. A new optional claim "msgi" provides a digest over a MIME body (i.e. body of the SIP MESSAGE). The PASSporT is conveyed in an Identity header field in the SIP MESSAGE request. The authentication and verification service procedures for populating that PASSporT follow the same procedures as for a voice session, with the addition of the "msgi" claim.

In today's PSTN, and for the foreseeable future, the Identity header may fail to arrive at the terminating service provider's network for verification by their AS for verification because the call is not transmitted using SIP end to end. However, Out-of-Band SHAKEN remedies this problem. A possible scenario is described in Figure E.2.4-1.

With this solution, the identity token is sent to the terminating service provider separately, out-of-band, through implementation of a Call Placement Service (CPS).All other SHAKEN steps for authentication, use of certificates and verification remain the same. CPS as defined in RFC 8816 permits the identity token to be stored during call processing and retrieved for verification purposes when a session is not using end-to-end SIP signaling, i.e. a leg in the session is using circuit switching and ISUP signaling. Out-of-Band SHAKEN is used when a service provider wants to use STIR/SHAKEN for a call sent or received across a non-SIP network segment. For example, Out-of-Band SHAKEN would be used in the following situations:

• A service provider originating a call using TDM signaling would generate the applicable PASSporTs using their AS for signing and publish them to a CPS.
• An Intermediate Service Provider converting a session from SIP to TDM would publish all PASSporTs received in SIP signaling for that call to a CPS.
• An Intermediate Service Provider converting a call from TDM to SIP would retrieve all PASSporTs for that call from a CPS and insert them into the SIP signaling for that call.
• A service provider terminating a call using TDM signaling would retrieve all PASSporTs for that call from a CPS and verify the call using their AS for verification.

Service providers originating, transiting, or terminating calls using only SIP signaling do not use Out-of-Band SHAKEN. They use PASSporTs in SIP signaling. Intermediate providers transiting calls with TDM signaling only do not use Out-of-Band SHAKEN. An upstream provider would have already published PASSporTs for those calls to a CPS. There is no need for an all-TDM intermediate provider to do anything as shown in Figure E.2.4-2. The interworking function (IWF) is the interface to the AS for signing at the originating side and the interface to the AS for verification at the terminated side.

In case of call forwarding, the original called party number is not the number to which a call is delivered. The SIP headers such as "History-Info", "Diversion" and "To" do not provide any cryptographic assurance of secure redirection. RFC 8946 extends the SIP identity token (i.e. PASSporT) with an explicit indication that the original called number no longer reflects the destination to which a call is intended to be delivered via a "div" parameter. It indicates a previous destination for a session during its routing process. When a retargeting entity receives a call signed with the SIP Identity token, it may act as an authentication service and create a new SIP Identity token containing the "div" parameter to attach to the session.

Two approaches, namely Rich Call Data (RCD) and eCNAM (Enhanced Calling Name) build on STIR/SHAKEN to provide additional caller information rendered to the callee during alerting to encourage the callee to answer the session.

RCD is described in an IETF draft draft-ietf-stir-passport-rcd-12 [42]. RCD is of two main categories. The first data is a more traditional set of information about a caller associated with "display-name", typically a textual description of the caller in the SIP INVITE. The second category is a set of RCD that is defined as part of the jCard (JSON format for vCard) as specified in RFC 7095. RCD is inserted in the SIP Identity header token and is digitally signed. If a session is not authenticated and signed then RCD cannot be used. While RCD can be provided by an originating authentication service, an intermediary in the session path could also acquire RCD by querying a third-party service. Such a service effectively acts as a STIR authentication service, generating its own Identity token including RCD, and that token could be attached to a SIP session by either the originating or terminating side.

The Enhanced Calling Name (eCNAM) service defined in TS 24.196 provides the terminating user with a name that identifies the originating user, and metadata about that originating user (e.g. address, language, etc.), like with RCD. eCNAM data is managed by the originating network and stored in an authoritative database. To enable the terminating network to retrieve eCNAM data, the terminating service provider queries the database using the calling telephone number as the key, to obtain calling display name and other metadata. In both RCD and eCNAM the terminating network shall populate the received name and received metadata elements in appropriate SIP headers in the INVITE request being forwarded to the terminating UE.