This Annex defines STIR (Secure Telephony Identity Revisited), SHAKEN (Secure Handling of Asserted information using toKENs), eCNAM (Enhanced Calling Name) and RCD (Rich Call Data) and their application to different call scenarios.
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.
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 an IETF draft draft-ietf-stir-messaging-00 
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 
, 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"
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"
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 
. 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.
The following procedure explains STIR/SHAKEN operation when SIP signaling is carried end-to-end between an originating and terminating service provider as illustrated in Figure E.4.1-1
The originating UE, which first successfully registers to IMS creates a SIP INVITE request.
The S-CSCF of the originating service provider passes the SIP INVITE request to the Telephony AS.
The Telephony AS runs the telephony services related to the originating user and:
May send a signing request (HTTP POST request) to the AS for signing. AS for signing using its private key generates an Identity header as defined in RFC 8224 using the Caller ID to attest for the validity of the calling number. The AS for signing returns the signing response (HTTP 200 OK) containing the Identity header to telephony AS. The Telephony AS signs the SIP INVITE request with the SIP Identity header. The Telephony AS also obtains Identity header for each diverting identity as defined in RFC 8946.
May not sign the SIP INVITE request with the SIP Identity header if it knows the egress IBCF supports invoking the AS for signing for providing an Identity header field.
The Telephony AS passes the SIP INVITE request back to the S-CSCF.
The S-CSCF, through standard resolution, routes the telephony session to the egress IBCF.
If the egress IBCF does not find an Identity header field in the received SIP INVITE request, the IBCF sends a signing request (HTTP POST request) to the AS for signing. When the response to the request is received, the IBCF shall include the value of the "identity" claim in an Identity header field in the SIP INVITE request. If the SIP INVITE request contains one or more History-Info header fields, that determine that one or several diversions have occurred, the IBCF sends a signing request for each of the identities to be signed if no corresponding Identity header fields are found in the SIP INVITE request. The IBCF shall include the value of the "identity" claim in an Identity header field in the SIP INVITE request.
The SIP INVITE request is routed over the NNI through the standard inter-domain routing configuration. The terminating service provider ingress IBCF receives the SIP INVITE request containing one or more Identity header fields over the NNI.
The IBCF uses the identity header fields to build and send a verification request (HTTPS POST request) to the AS for verification related to the originating identity and forwarding identities if the IBCF supports invoking the AS for verification.
The AS for verification uses the "x5u" key in the Identity header field to determine the CR Uniform Resource Identifier (URI) and makes an HTTPS request to the CR. The AS for verification validates the certificate and then extracts the public key. It uses the public key to verify the signature in the Identity header field, which validates the Caller ID used when signing the SIP INVITE request on the originating service provider's AS for signing.
The AS for verification returns a verification response (200 OK) to the ingress IBCF which adds the verification result (TN-Validation-Passed, TN-Validation-Failed, No-TN-Validation) as a VERSTAT parameter to the P-Asserted-Identity or From header in the SIP INVITE request. The TN-Validation-Failed result is associated with a failure response code to identify the specific error. The standard does not propose any authorization policy to follow based on the presence of a valid Identity header field, the presence of an invalid Identity header field or the absence of an Identity header field. However, it is anticipated that local policies could involve making different forwarding decisions or changing how the user is alerted or how identity is rendered in UE implementations.
The ingress IBCF passes the SIP INVITE request to the terminating S-CSCF.
The terminating S-CSCF passes the SIP INVITE request to the terminating Telephony AS.
If the verification has not been performed by the ingress IBCF, the Telephony AS runs the verification procedure toward the AS for verification before running the telephony services related to the terminating identity.
If the validation is successful, the SIP INVITE request is passed back to the terminating S-CSCF which continues to set up the session to the terminating UE.
The terminating UE receives the SIP INVITE request and normal SIP processing of the session continues.