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 RFC 9475. 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 session 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 RFC 9475, 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 signalling, i.e. a leg in the session is using circuit switching and ISUP signalling. 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 signalling 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 signalling 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 signalling for that call.
• A service provider terminating a call using TDM signalling 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 signalling do not use Out-of-Band SHAKEN. They use PASSporTs in SIP signalling. Intermediate providers transiting calls with TDM signalling 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.

5G ProSe Direct Discovery is defined as the procedure used by the ProSe-enabled UE to discover other ProSe-enabled UE(s) in its proximity using NR direct radio signals using the PC5 interface without going via the network. Two possible Direct Discovery models exist:

• Model A ("I am here"): In this model, the UE announces its presence to other UE(s) who are interested in reading and/or processing the messages. The UE that announces certain information that could be used by other UE(s) in proximity is called the "announcing" UE. The UE that has the permission to discover and the interest to read and/or process messages from an "announcing" UE in proximity is called the "monitoring" UE.
• Model B ("who is there" and/or "are you there"): In this model, the UE tries to discover other UE(s) by sending a request containing certain information. The UE that transmits a request containing certain information about what it is interested to discover is called the "discoverer" UE. The UE that receives and processes the request message and responds with some information related to the discoverer's request is called the "discoveree" UE.

The ProSe Discovery feature is defined in an "open" mode and in a "restricted" mode. For the open mode, no permission is needed from the UE that is to be discovered, while the restricted mode requires permission from the UE that is being discovered. A UE may be:

• An announcing UE requesting the DDNMF ProSe application code(s) to be announced over 5G ProSe-enabled radio interface (PC5) to UEs in proximity or informing the 5G DDNMF that the UE wants to stop announcing Prose application code.
• A monitoring UE requesting to the DDNMF the discovery filter(s) corresponding to a ProSe application ID to perform direct discovery monitoring corresponding to this ProSe application ID or informing the 5G DDNMF that the UE wants to stop using discovery filter(s) for direct discovery monitoring.
• A discoverer UE requesting query code (s) and discovery response filter(s) to its DDNMF to be used for sending query and monitoring responses over the PC5 interface respectively.
• A discoveree UE requesting discovery query filter(s) to its DDNMF to be used for monitoring query sent by discoverer UE over the PC5 interface and ProSe response code to be announced over the PC5 interface as a response to the query.

Figure G.2.1-1 shows Direct Discovery procedure for Model A in an open mode. When the UE announces its presence, it initiates a discovery request for announcing to the DDNMF in its HPLMN. The discovery request contains the ProSe Application ID of the application whose availability is intended to be announced. If the request is successful, it obtains the ProSe Application Code from the 5G DDNMF in its HPLMN. The ProSe Application Code is a temporary code that corresponds to the ProSe Application ID and it is UE specific. It is used to enable monitoring UE to discover the presence of the announcing UE. Each ProSe Application Code is composed from a temporary identity and a PLMN ID that corresponds to the PLMN that assigned the ProSe Application Code. The UE uses the Application Code for the announcing procedure over the PC5 interface. When the UE is triggered by an application to monitor for other UEs that are in proximity and it has the authorization to monitor, it initiates a discovery request for monitoring towards the DDNMF in its HPLMN. The request includes the Application ID. If the request is successful, it obtains the Discovery Filter(s). A Discovery Filter is a container of a ProSe Application code, zero or more ProSe Application Mask(s) and Time To Live value. Then the monitoring UE starts monitoring for these ProSe Application Code(s) on the PC5 interface. When the UE detects that one or more advertised ProSe Application Code(s) match the given filter, it reports these ProSe Application Code(s) to the ProSe Function using a Match report.

The overall procedure for 5G ProSe Direct Discovery (Model A) is described in clause 6.3.1.2 of TS 23.304. The overall procedure for 5G ProSe Direct Discovery (Model B) is described in clause 6.3.1.3 of TS 23.304. If the UE wants to announce in a VPLMN, the announcing UE sends a discovery request containing the ProSe Application ID to the 5G DDNMF in its HPLMN in order to be allowed to announce an Application Code on its serving PLMN (i.e., VPLMN). If the announcing UE wants to send announcements in the VPLMN, it needs to be authorized from the 5G DDNMF in the VPLMN. The 5G DDNMF in the HPLMN requests authorization from the 5G DDNMF in the VPLMN. If authorization is granted, DDNMF in the HPLMN returns the code to the announcing UE. If the monitoring UE wants to monitor in a VPLMN or local PLMN, the monitoring UE requests the discovery filters to the DDNMF in its HPLMN in order to be allowed to monitor on its serving PLMN (i.e., VPLMN, Local PLMN). The 5G DDNMF in the HPLMN requests authorization from the 5G DDNMF in the VPLMN or Local PLMN. If authorization is granted, DDNMF in the HPLMN returns the discovery filters to the monitoring UE.