Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 33.128  Word version:  18.6.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.7…   6…   6.2.2.2A…   6.2.3…   6.2.3.2.7…   6.2.3.3…   6.2.4…   6.3…   6.3.2.2A…   6.3.3…   6.3.3.2…   6.3.3.2.4…   6.3.3.2A…   7…   7.3…   7.3.3…   7.3.3.2.21…   7.3.3.2.42…   7.3.3.2.63…   7.3.4…   7.4…   7.4.3.8…   7.5…   7.6…   7.7…   7.7.4…   7.8…   7.8.4…   7.9…   7.10…   7.10.4…   7.11…   7.12…   7.13…   7.13.3…   7.13.3.4…   7.14…   7.15…   8…   A…   D…   E…   M… 
7.11 STIR/SHAKEN and RCD/eCNAM  7.11.1 Provisioning over LI_X1  7.11.1.1 General  7.11.1.2 Provisioning of the IRI-POI in the IMS network functions  7.11.1.3 Provisioning of the MDF2  7.11.2 Generation of xIRI at IRI-POI in the IMS Network Functions over LI_X2  7.11.2.1 General  7.11.2.2 Signature generation  7.11.2.3 Signature validation  7.11.2.4 IMS Network Function that interacts with signing AS  7.11.2.5 IMS Network Function that interacts with the verification AS  7.11.3 Generation of IRI over LI_HI2 
...

 

7.11  STIR/SHAKEN and RCD/eCNAM  p. 297

7.11.1  Provisioning over LI_X1  p. 297

7.11.1.1  General  p. 297

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.
Up

7.11.1.2  Provisioning of the IRI-POI in the IMS network functions  p. 297

The LIPF provisions the IRI-POIs present in the NFs mentioned in clause 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.
ETSI TS 103 221-1 [7] field name Description M/C/O
XIDXID assigned by LIPF.M
TargetIdentifiersThe 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
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.
Up

7.11.1.3  Provisioning of the MDF2  p. 298

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.
ETSI TS 103 221-1 [7] field name Description M/C/O
XIDXID assigned by LIPF.M
TargetIdentifiersThe 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
ETSI TS 103 221-1 [7] field name Description M/C/O
LIIDLawful Intercept ID associated with the task.M
DeliveryType Set to "HI2Only". M
ListOfDIDsDetails 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
Up

7.11.2  Generation of xIRI at IRI-POI in the IMS Network Functions over LI_X2  p. 298

7.11.2.1  General  p. 298

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 clause 7.14.3 of TS 33.127, each of which is described in the following clauses.
Up

7.11.2.2  Signature generation  p. 298

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.
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 2 below). Shall be provided. This parameter is conditional only for backwards compatibility.C
NOTE 1:
Void.
NOTE 2:
The same SIP message may be encapsulated in the xIRI IMSMessage as well.
Field Name Description M/C/O
pASSporTHeader PASSporT Header as defined in Section 4 of RFC 8224 for "shaken" PASSporT, in Section 3 of RFC 8946 for "div" PASSportT and in TS 24.229. See Table 7.11.2.2-3. M
pASSporTPayload PASSporT Payload as defined in Section 4 of RFC 8224 for "shaken" PASSporT, in Section 3 of RFC 8946 for "div" PASSporTand in TS 24.229. See Table 7.11.2.2-4. M
pASSporTSignature PASSporT Signature as defined in Section 4 of RFC 8224 for "shaken" PASSporT, in Section 3 of RFC 8946 for "div" PASSporTand in TS 24.229. M
Field Name Description M/C/O
type Shall be populated with the type contained in the PASSporT Header as defined in Section 4.1 of RFC 8225 for "shaken" PASSporT and in Section 3 of RFC 8946 for "div" PASSporT. M
algorithm Shall be derived from the value of the 'alg' parameter of the PASSporT Header as defined in Section 4.2 of RFC 8225 for "shaken" PASSporT and in Section 3 of RFC 8946 for "div" PASSporT. M
ppt Shall be derived from the value of the 'ppt' parameter of the PASSporT Header as defined in Section 8.1 of RFC 8225 for "shaken" PASSporT if the PASSporT Header contains a ppt parameter and in Section 3 of RFC 8946 for "div" PASSporT. C
x5u Shall be populated with the URI contained in the 'x5u' parameter of the PASSporT Header as defined in Section 4.3 of RFC 8225 for "shaken" PASSporT and in Section 3 of RFC 8946 for "div" PASSporT. M
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 Section 5.1.1 of RFC 8225 and in Section 3 of RFC 8946. M
originator Shall be populof ated with the value of the "orig" claim of the PASSporT Payload as defined in Section 5.2.1 of RFC 8225 and in Section 3 of RFC 8946. M
destination Shall contain the list of destinations contained in the "dest" claim of the PASSporT Payload as defined in Section 5.2.1 of RFC 8225 and in Section 3 of RFC 8946. 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 Section 3 of RFC 8946 for "div" PASSporT. C
attestation Indicates the attestation level as defined in Section 4 of RFC 8588 for the "shaken" PASSporT. The different values of attestation level are A = Full Attestation, B= Partial Attestation, C = Gateway Attestation. For "div" PASSporT where "attestation" is not available, the placeholder value "Not available" shall be used. M
origID Shall be populated with the value of the origID contained in the 'origid' parameter of the PASSporT Payload as defined in Section 5 of RFC 8588 for the "shaken" PASSporT. For "div" PASSporT where "origId" is not available, the placeholder value "Not available" shall be used. M
NOTE 3:
Void.
NOTE 4:
Void.
Up

7.11.2.3  Signature validation  p. 301

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.
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.
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 and RFC 8224.
This is a set of PASSporT parameter. See Table 7.11.2.2-2.		C
rCDTerminalDisplayInfoRCD display information when applicable. See IETF draft-ietf-stir-passport-rcd-12 [73].C
eCNAMTerminalDisplayInfoeCNAM display information when applicable. See TS 24.196.C
sHAKENValidationResult SHAKEN validation result: TN-Validation-Passed, TN-Validation-Failed, No-TN-Validation. See TS 24.229 and RFC 8588.M
sHAKENFailureStatusCode SHAKEN status code when validation fails in the terminating network. See RFC 8224.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.
Up

7.11.2.4  IMS Network Function that interacts with signing AS  p. 302

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  p. 303

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.
Up

7.11.3  Generation of IRI over LI_HI2  p. 303

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.
IRI message Record type
STIRSHAKENSignatureGenerationREPORT
STIRSHAKENSignatureValidationREPORT
Up

Up   Top   ToC