E.2 STIR/SHAKEN

33.1273GPPLawful Interception (LI) architecture and functionsRelease 18TS

E.2.1 STIR/SHAKEN for telephony

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 3GPP TS 24.229 [39] when using end-to-end SIP signalling.

Figure E.2.1-1: SHAKEN reference architecture for end-to-end SIP signaling

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 [40] for originating number identity and in RFC 8946 [41] 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 [40] and in RFC 8946 [41]. 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 [40] 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.

E.2.2 STIR/SHAKEN for intra-network telephony

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.

Figure E.2.2-1: SHAKEN reference architecture for intra-network telephony

E.2.3 STIR/SHAKEN for messaging

STIR/SHAKEN could apply to providing protection for textual and multimedia messaging as specified in an IETF draft draft-ietf-stir-messaging-00 [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-00 [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.

E.2.4 Out of band SHAKEN

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.

Figure E.2.4-1: Out of band SHAKEN reference architecture for non end-to-end SIP signaling

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 [45] 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.3.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.

Figure E.2.4-2: Out of band SHAKEN reference architecture for end-to-end TDM signaling

E.2.5 STIR/SHAKEN and forwarded calls

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 [41] 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.