7.11 STIR/SHAKEN and RCD/eCNAM
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.11.1 Provisioning over LI_X1
7.11.1.1 General
When the interception of STIR/SHAKEN is required, the LIPF shall provision the IRI-POI present in the following IMS NFs for the reporting of signing and verification results, as applicable:
– IBCF.
– Telephony AS.
If the IRI-POI functions in IBCF or Telephony AS are already provisioned for IMS-based services, then separate provisioning is not required. However, the "ReportDiversionPASSporTInfo" shall be included, as specified in clause 7.11.1.2, as a part of provisioning the IRI-POIs in Telephony AS and IBCF for IMS-based services.
NOTE: The P-CSCF and LMISF-IRI may also provide IRI-POI functions for reporting of STIR/SHAKEN validation results when the target (or user communicating with the target non-local ID) is roaming (P-CSCF with LBO and LMIF-IRI with home-routed). However, separate provisioning of those IRI-POIs for STIR/SHAKEN is not required.
7.11.1.2 Provisioning of the IRI-POI in the IMS network functions
The LIPF provisions the IRI-POIs present in the NFs mentioned in 7.11.1.1 using the X1 protocol as described in clause 5.2.2 with the following target identifier formats as defined in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– IMPU.
The "div" PASSporT information for the redirecting party (ies) when the IMS session is redirected later on the signaling path may have to be reported to some LEAs. To identify the need for such reporting, a parameter "ReportDiversionPASSporTInfo" shall be included as part of ActivateTask message.
Table 7.11.1.2-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI-POI in the Telephony AS, IBCF, for separate provisioning case, for STIR/SHAKEN and RCD/eCNAM.
Table 7.11.1.2-1: ActivateTask message for IRI-POI in the IMS Network Functions for STIR/SHAKEN and RCD/eCNAM
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
The target identifier listed in the paragraph above. |
M |
|
DeliveryType |
Set to "X2Only". |
M |
|
ListOfDIDs |
Delivery endpoints of LI_X2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
TaskDetailsExtensions/ STIRSHAKENProvisioning |
Shall be included if the interception of STIR/SHAKEN is required. See table 7.11.1.2-2. |
C |
Table 7.11.1.2-2: STIRSHAKENProvisioning extension
|
Extensions field name |
Description |
M/C/O |
|
ReportDiversionPASSporTInfo |
Indicates whether "div" PASSporT information of redirecting party(ies) when the IMS session is redirected later on the signaling path is to be reported. When set to "true" or absent, it shall be reported. When set to "false" or absent, it shall not be reported. |
M |
When the IRI-POIs in Telephony AS or IBCF are provisioned for IMS-based services, then the minimal details of LI_X1 ActivateTask message shall be as defined in clause 7.12.3.2.1 (table 7.12.3.2-2) with the addition of "ReportDiversionPASSporTInfo" parameter.
7.11.1.3 Provisioning of the MDF2
This clause is applicable when the MDF2 is not provisioned for IMS-based interception.
The MDF2 listed as the delivery endpoint for xIRI generated by the IRI-POI in the IMS Network Functions for STIR/SHAKEN and RCD/eCNAM shall be provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2. Table 7.11.1.3-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the MDF2.
The MDF2 shall support the following target identifier formats in the ETSI TS 103 221-1 [7] messages (or equivalent if ETSI TS 103 221-1 [7] is not used):
– IMPU.
Table 7.11.1.3-1: ActivateTask message for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
The target identifier listed in the paragraph above. |
M |
|
DeliveryType |
Set to “X2Only". (Ignored by the MDF2). |
M |
|
ListOfDIDs |
Delivery endpoints of LI_HI2. These delivery endpoints shall be configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
ListOfMediationDetails |
Sequence of Mediation Details, see table 7.11.1.3-2. |
M |
Table 7.11.1.3-2: Mediation Details for MDF2
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
LIID |
Lawful Intercept ID associated with the task. |
M |
|
DeliveryType |
Set to "HI2Only". |
M |
|
ListOfDIDs |
Details of where to send the IRI for this LIID. Shall be included if deviation from the ListofDIDs in the ActivateTask message is necessary. If included, the ListOfDIDs in the Mediation Details shall be used instead of any delivery destinations authorised by the ListOfDIDs field in the ActivateTask Message. |
C |
7.11.2 Generation of xIRI at IRI-POI in the IMS Network Functions over LI_X2
7.11.2.1 General
The IRI-POI present in the IMS Network Functions for STIR/SHAKEN and RCD/eCNAM shall send xIRI over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.14.3, each of which is described in the following clauses.
NOTE: The clauses below on signing and verification shall be applied for diverted call based on the RFC 8946 [76]. LI system has to generate xIRI containing all the pASSporT objects of the SIP messages and signature validation or generation results, even those of the History-Info field.
7.11.2.2 Signature generation
The IRI-POI present in the Telephony AS or IBCF, shall generate an xIRI containing a STIRSHAKENSignatureGeneration record under the following conditions:
– Telephony AS or IBCF is interacting with the SIGNING AS. Whether it is the Telephony AS or IBCF for sessions is based on network configuration and local policy of the CSP as described in clause 7.11.2.4.
– When P-Asserted Identity or From header of SIP INVITE request received from S-CSCF is a target identity with the conditions mentioned below:
– The identities in one or both of those headers are used to interact with the SIGNING AS.
– The "shaken" PASSporT is not received in the SIP INVITE request from the S-CSCF.
– The "shaken" PASSporT is received from the SIGNING AS.
– The "shaken" PASSporT is included in the outgoing SIP INVITE.
– When the "ReportDiversionPASSporTInfo" parameter is set to "True" in the ActivateTask with P-Asserted Identity or From header of SIP INVITE request received from S-CSCF is a target identity with the conditions mentioned below:
– The identities in one or both of those headers are used to interact with the SIGNING AS.
– A "shaken" PASSporT or a "div" PASSporT with those identities are included in the "orig" claim of "shaken" or "div" PASSporT received from the SIGNING AS.
– The "shaken" PASSporT or a "div" PASSporT with those identities are included in the "orig" claim of "shaken" or "div" PASSporT in the outgoing SIP INVITE.
– When Diversion header or the History Info of SIP INVITE request received from the S-CSCF includes a target identity with the conditions mentioned below:
– The identities in one or both of those headers are used to interact with the SIGNING AS.
– The "div" PASSporT with those identities in the "div" claim is not received in the SIP INVITE request from the S-CSCF.
– The "div" PASSporT with those identities in the "div" claim is received from the SIGNING AS.
– The "div" PASSporT with those identities in the "div" claim is included in the outgoing SIP INVITE.
– When the "ReportDiversionPASSporTInfo" parameter is set to "True" in the ActivateTask with Diversion or HistoryInfo header of SIP INVITE request received from S-CSCF includes the target identity with the conditions mentioned below:
– The identities in P-Asserted Identity or From of SIP INVITE received from the S-CSCF are used to interact with the SIGNING AS.
– A "div" PASSporT with the identities in P-Asserted Identity or From of SIP INVITE request received from S-CSCF are included in the "orig" claim of "div" PASSporT received from the SIGNING AS.
– The "div" PASSporT with the identities in P-Asserted Identity or From of SIP INVITE request received from S-CSCF are included in the "orig" claim of "div" PASSporT in the outgoing SIP INVITE.
– When Request URI of outgoing SIP INVITE is a target non-local ID and is present in the "dest" claim of "shaken" or "div" PASSporT received from the SIGNING AS and the same is included in the outgoing SIP INVITE.
– When Telephony AS is interacting with the SIGNING AS, and when Request URI of SIP INVITE received from the S-CSCF is a target identity with the conditions mentioned below:
– The identity is used to interact with the SIGNING AS.
– The "div" PASSporT with that identity in the "div" claim is received from the SIGNING AS.
– The "div" PASSporT with that identity in the "div" claim is included in the outgoing SIP INVITE.
When the target is not a non-local ID, the STIRSHAKENSignatureGeneration includes only the PASSporT received in the SIGING AS response with the following rules:
– When the "ReportDiversionPASSporTInfo" parameter is set to "True" in the ActivateTask, all of the PASSporT received from the SIGNING AS.
– When the "ReportDiversionPASSporTInfo" parameter is set to "False" in the ActivateTask:
– If P-Asserted Identity or From header in the SIP INVITE received from the S-CSCF is a target identity, then only "shaken" PASSporT received from the SIGNING AS with those identities in the "orig" claim of the "shaken" PASSporT.
– If Diversion or HistoryInfo header in the SIP INVITE received from the S-CSCF is a target identity, then only the "div" PASSporT received from the SIGNING AS with those identities in the "div" claim of "div" PASSporT.
– If REQUEST URI or To header in the SIP INVITE received from the S-CSCF is a target identity, then only the "div" PASSporT received from the SIGNING AS with those identities in the "div" claim of "div" PASSporT.
When the target is non-local ID, STIRSHAKENSignatureGeneration includes all of the PASSporT included in the outgoing SIP message.
The following table contains parameters, with IRITargetIdentifier, generated by the IRI-POI.
Table 7.11.2.2-1: Payload for STIRSHAKENSignatureGeneration record
|
Field name |
Description |
M/C/O |
|
pASSporTs |
Identifies the content of the SIP Identity headers added by the originating network and transit networks. This is a set of PASSporT parameter. See table 7.11.2.2-2. |
M |
|
encapsulatedSIPMessage |
Encapsulated SIP INVITE request that includes SIP Identity header carrying the PASSporT (Outgoing SIP request) based on the structure defined in table 7.12.4.2-2 (see NOTE below). |
M |
|
NOTE 1: For the backward compatibility purposes the parameter is coded as OPTIONAL in the ASN.1 schema (Annex A). NOTE 2: The same SIP message may be encapsulated in the xIRI IMSMessage as well. |
||
Table 7.11.2.2-2: Details for PASSporT parameter
|
Field name |
Description |
M/C/O |
|
pASSporTHeader |
PASSporT Header as defined in RFC 8224 [70] clause 4 for "shaken” PASSporT, in RFC 8946 [76] clause 3 for "div” PASSportT and in TS 24.229 [74]. See table 7.11.2.2-3. |
M |
|
pASSporTPayload |
PASSporT Payload as defined in RFC 8224 [70] clause 4 for "shaken” PASSporT, in RFC 8946 [76] clause 3 for "div” PASSporTand in TS 24.229 [74]. See table 7.11.2.2-4. |
M |
|
pASSporTSignature |
PASSporT Signature as defined in RFC 8224 [70] clause 4 for "shaken” PASSporT, in RFC 8946 [76] clause 3 for "div” PASSporTand in TS 24.229 [74]. |
M |
Table 7.11.2.2-3: Details for pASSporTHeader parameter
|
Field name |
Description |
M/C/O |
|
type |
Shall be populated with the type contained in the PASSporT Header as defined in RFC 8225 [69] clause 4.1 for "shaken” PASSporT and in RFC 8946 [76] clause 3 for "div” PASSporT. |
M |
|
algorithm |
Shall be derived from the value of the ‘alg’ parameter of the PASSporT Header as defined in RFC 8225 [69] clause 4.2 for "shaken” PASSporT and in RFC 8946 [76] clause 3 for “div” PASSporT. |
M |
|
ppt |
Shall be derived from the value of the ‘ppt’ parameter of the PASSporT Header as defined in RFC 8225 [69] clause 8.1 for “shaken” PASSporT if the PASSporT Header contains a ppt parameter and in RFC 8946 [76] clause 3 for “div” PASSporT. |
C |
|
x5u |
Shall be populated with the URI contained in the ‘x5u’ parameter of the PASSporT Header as defined in RFC 8225 [69] clause 4.3 for “shaken” PASSporT and in RFC 8946 [76] clause 3 for "div” PASSporT. |
M |
Table 7.11.2.2-4: Details for pASSporTPayload parameter
|
Field name |
Description |
M/C/O |
|
issuedAtTime |
Shall be populated with the GenrealizedTime format timestamp converted from the NumericDate contained in the ‘iat’ parameter of the PASSporT Payload as defined in RFC 8225 [69] clause 5.1.1 and in RFC 8946 [76] clause 3. |
M |
|
originator |
Shall be populated with the value of the "orig" claim of the PASSporT Payload as defined in RFC 8225 [69] clause 5.2.1 and in RFC 8946 [76] clause 3. |
M |
|
destination |
Shall contain the list of destinations contained in the "dest" claim of the PASSporT Payload as defined in RFC 8225 [69] clause 5.2.1 and in RFC 8946 [76] clause 3. |
M |
|
diversion |
Shall be populated with the "div" claim of the "div" PASSporT payload. For first diversion this contains the original identifier of the destination as defined in RFC 8946 [76] clause 3 for “div" PASSporT. |
C |
|
attestation |
Indicates the attestation level as defined in RFC 8588 [71] clause 4 for the "shaken” PASSporT. The different values of attestation level are A = Full Attestation, B= Partial Attestation, C = Gateway Attestation (See NOTE 3 below). |
M |
|
origID |
Shall be populated with the value of the origID contained in the ‘origid’ parameter of the PASSporT Payload as defined in RFC 8588 [71] clause 5 for the “shaken” PASSporT (See NOTE 4 below). |
M |
|
NOTE 3: For the backward compatibility purposes the parameter is coded as MANDATORY in the ASN.1 schema (Annex A). ‘attestation’ is mandatory for "shaken" PASSporT and absent for "div" PASSporT. Therefore, for div PASSporT, since "attestation" is not available, the placeholder value “Not available” shall be used. NOTE 4: For the backward compatibility purposes the parameter is coded as MANDATORY in the ASN.1 schema (Annex A). This parameter is mandatory for "shaken" PASSporT and absent for the "div" PASSporT. Therefore, for div PASSporT, since "origId" is not available, the placeholder value “Not available” shall be used. |
||
7.11.2.3 Signature validation
The IRI-POI present in the Telephony AS or IBCF, shall generate an xIRI containing a STIRSHAKENSignatureValidation record when the following conditions are met:
– Either IBCF or Telephony AS, is interacting with the VERIFICATION AS. Whether it is the Telephony AS or IBCF for sessions is based on network configuration and local policy of the CSP as described in clause 7.11.2.5.
– With one or more of the following are true:
– Request URI and To Headers of SIP INVITE request received from S-CSCF (in the case of Telephony AS) or from the previous IP network (in the case of IBCF) is a target identity.
– One or more of P-Asserted Identity, From, Diversion, History-Info Headers of SIP INVITE request received from S-CSCF (in the case of Telephony AS) or from the previous IP network (in the case of IBCF) is a target non-local identity without any prior intra-network diversions.
– If PASSporTs are received in the SIP INVITE request, they are submitted by the IBCF to the VERIFICATION AS for validation and the result is included in an outgoing SIP INVITE request together with possible RCD data or eCNAM data as Call-Info headers.
– If PASSporTs are received in the SIP INVITE request, they are submitted by the Telephony AS to the VERIFICATION AS for validation and the validation result is received from the Verification AS and the outgoing SIP INVITE possibly includes RCD data or eCNAM data as Call-Info headers.
NOTE: The IRI-POI may use the Via headers, Record-route headers to determine any prior intra-network diversions.
The IRI-POI present in the Telephony AS shall also generate an xIRI containing a STIRSHAKENSignatureValidation record when it detects the following conditions:
– Session is redirected.
– Request URI header of outgoing SIP INVITE is a target identity.
– Validation result is included in the outgoing SIP INVITE with the possible the RCD data and the eCNAM data as Call-Info headers.
The IRI-POI present in the LMISF-IRI or P-CSCF shall generate an xIRI containing a STIRSHAKENSignatureValidation record when the following conditions are met:
– With one or more of the following are true:
– Request URI or To header of SIP INVITE request sent to the UE is a target identity.
– One or more of P-Asserted Identity, From, Diversion, History-Info Headers of SIP INVITE request sent to the UE is a target non-local identity.
– SIP INVITE request sent to the UE includes SIP Call-Info headers containing possible RCD data or eCNAM data, and the result of the PASSporT verification.
In the above paragraphs, a validation result (i.e. result of all PASSporT verification) is included means a "verstat" parameter within the P-Asserted Identity header is included in the outgoing SIP INVITE.
The following table contains parameters, with IRITargetIdentifier, generated by the IRI-POI.
Table 7.11.2.3-1: Payload for STIRSHAKENSignatureValidation record
|
Field name |
Description |
M/C/O |
|
pASSporTs |
Identifies the content of the SIP Identity headers added by the originating network and transit networks. See TS 24.229 [74] and RFC 8224 [70]. This is a set of PASSporT parameter. See table 7.11.2.2-2. |
C |
|
rCDTerminalDisplayInfo |
RCD display information when applicable. See IETF draft-ietf-stir-passport-rcd-12 [73]. |
C |
|
eCNAMTerminalDisplayInfo |
eCNAM display information when applicable. See TS 24.196 [72]. |
C |
|
sHAKENValidationResult |
SHAKEN validation result: TN-Validation-Passed, TN-Validation-Failed, No-TN-Validation. See TS 24.229 [74] and IETF RFC 8588 [71]. |
M |
|
sHAKENFailureStatusCode |
SHAKEN status code when validation fails in the terminating network. See IETF RFC 8224 [70]. |
C |
|
encapsulatedSIPMessage |
Encapsulated SIP INVITE request that carries P-Asserted Identifier or From header that includes the SHAKEN validation result (Outgoing SIP request) based on the structure defined in table 7.12.4.2-2. (see NOTE below). |
C |
|
NOTE: The same SIP message may be encapsulated in the xIRI IMSMessage as well. |
||
When the termination network performs SHAKEN verification, one of the following values shall be assigned to the SHAKEN validation result parameter as part of the display information: "TN-Validation-Passed", "TN-Validation-Failed", or "No-TN-Validation". In case of TN-Validation-Failed, the SHAKEN failure status code shall be present and coded as an integer. The SHAKEN failure status codes are at least, according to RFC 8224 and to IANA Session Initiation Protocol (SIP) Parameters [75]:
– 403 "Stale Date" response code is sent when the verification service receives a request with a Date header field value that is older than the local policy of the CSP for freshness permits. The same response may be used when the "iat" has a value older than the local policy of the CSP for freshness permits.
– 428 "Use Identity Header" response code is sent when the verification service receives a SIP request that lacks an Identity header. This is to indicate that the request should be re-sent with an Identity header.
– 436 "Bad Identity-Info" response code is used to indicate an inability to acquire the credentials needed by the verification service for validating the signature in an Identity header field.
– 437 "Unsupported Credential" response code is used when the verification service cannot validate the certificate referenced by the URI of the Identity-Info header, for reasons such as failing to trust the issuing certification authority (CA) or failing to support the algorithm with which the credential was signed.
– 438 "Invalid Identity Header" response code is used to indicate that of the set of Identity header fields in a request, no header field with a valid and supported Identity token has been received.
7.11.2.4 IMS Network Function that interacts with signing AS
The Telephony AS interacts with the SIGNING AS when any of the following is true:
– RCD is supported.
– Intra-CSP session signing is required.
– CSP choice for signing is AS.
The IBCF interacts with the SIGNING AS when all of the following are true:
– RCD is not supported.
– Intra-CSP session signing is not required.
– CSP choice for signing is IBCF.
The IBCF also interacts with the SIGNING AS for an IMS emergency session.
The presence of RCD is on a per call basis.
7.11.2.5 IMS Network Function that interacts with the verification AS
The Telephony AS interacts with the VERIFICATION AS when any of the following is true:
– Intra-CSP session verification is required.
– CSP choice for verification is AS.
– CSP choice for emergency session callback verification is AS.
The IBCF interacts with the VERIFICATION AS when all of the following are true:
– Intra-CSP session verfication is not required.
– CSP choice for verification is IBCF.
The IBCF also interacts with the VERIFICATION AS for an IMS emergency session callback when the CSP choice for verification for emergency callback session is IBCF.
7.11.3 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from an IRI-POI, the MDF2 shall generate the corresponding IRI message and deliver over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record (STIRSHAKENSignatureGeneration or STIRSHAKENSignatureValidation) received in the xIRI over LI_X2.
The MDF2 shall able to remove information regarded as content from RCD or eCNAM parameters in the case of an IRI-only warrant. The details of what needs to be removed and under what circumstances are outside the scope of the present document.
The timeStamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time present in the timestamp field of the xIRI.
The threeGPP33128DefinedIRI field (see ETSI TS 102 232-7 [10] clause 15) shall be populated with the BER-encoded IRIPayload.
The STIRSHAKENSignatureGeneration and STIRSHAKENSignatureValidation IRI messages shall have the same CIN as in the other IRI messages delivered for the IMS session (see ETSI TS 102 232-1 [9] clause 5.2.4).
The IRI type parameter (see ETSI TS 102 232-1 [9] clause 5.2.10) shall be included and coded according to table 7.11.3-1.
Table 7.11.3-1: IRI type for IRI messages
|
Record type |
IRI Type |
|
STIRSHAKENSignatureGeneration |
REPORT |
|
STIRSHAKENSignatureValidation |
REPORT |