7.9 LI for services encrypted by CSP-provided keys
33.1283GPPProtocol and procedures for Lawful Interception (LI)Release 18SecurityStage 3TS
7.9.1 LI for general AKMA-based service
7.9.1.1 General
This clause describes basic IRI-intercept for a generic, encrypted service between a target UE and an application in the CSP network, making use of AKMA-provided cryptographic keys according to TS 33.535 [65].
7.9.1.2 Provisioning over LI_X1
7.9.1.2.1 General
The IRI-POI in the AAnF (AKMA Anchor Function) and the MDF2 shall be provisioned.
Details of provisioning of an IRI-POI at a network internal AF (Application Function) making use of AKMA services of the AAnF is in general service specific and not part of the present clause. Generally, triggering, rather than provisioning, could in some cases be necessary for the AF. An application independent generic triggering mechanism is defined in clause 7.9.1.2.3.
Provisioning of CC-intercept at the AF is service specific and not covered in the present document.
7.9.1.2.2 Provisioning of the IRI-POI in AAnF
The IRI-POI present in the AAnF is provisioned over LI_X1 by the LIPF using the X1 protocol as described in clause 5.2.2.
The IRI-POI in the AAnF shall support the following target identifier formats:
– SUPI, given in either SUPIIMSI or SUPINAI formats as defined in ETSI TS 103 120 [6] clause C.2.
Table 7.9.1.2-1 shows the minimum details of the LI_X1 ActivateTask message used for provisioning the IRI POI in the AAnF.
Table 7.9.1.2-1: ActivateTask message for the IRI-POI in the AAnF
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
XID assigned by LIPF. |
M |
|
TargetIdentifiers |
One of the target identifiers listed in the paragraph above. |
M |
|
DeliveryType |
Set to "X2Only". |
M |
|
ListOfDIDs |
Delivery endpoints for LI_X2 for the IRI-POI in the AMF. These delivery endpoints are configured using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to the task activation. |
M |
7.9.1.2.3 Triggering of the IRI-POI in AF
The IRI POI present in an AF providing services based on identifiers other than SUPI shall be triggered by the IRI-TF present in the AAnF over LI_T2 using the X1 protocol as described in clause 5.2.2. An AAnF can provide services for several different types of applications. Provision could be service/application specific, which can effect whether or not certain conditional fields are included in the xIRI described below.
When the IRI-TF in the AAnF detects that an A-KID has been associated with a SUPI (see clause 7.9.1.3.2), it shall send an ActivateTask message to the IRI POI present in the AF. The same shall apply if the AAnF detects that the A-KID of a target changes due to primary authentication. The ActivateTask message shall contain at least the following information.
Table 7.9.1.2-2: ActivateTask message for triggering the IRI-POI in the AF
|
ETSI TS 103 221-1 [7] field name |
Description |
M/C/O |
|
XID |
Allocated by the IRI-TF as per ETSI TS 103 221-1 [7]. |
M |
|
TargetIdentifiers |
AKID associated with the AKMA Anchor Key (see table 7.9.1.3-3 below). |
M |
|
DeliveryType |
Set to “X2Only”. |
M |
|
ListOfDIDs |
Delivery endpoints for LI_X2. These delivery endpoints shall be configured by the IRI-TF in the SMF using the CreateDestination message as described in ETSI TS 103 221-1 [7] clause 6.3.1 prior to first use. |
M |
|
implicitDeactivationAllowed |
Shall be set to "True". |
M |
|
ProductID |
Shall be set to the XID of the Task Object associated with the interception at the CC-TF. This value shall be used by the CC-POI in the UPF to fill the XID of X3 PDUs. |
M |
Table 7.9.1.2-3: Target Identifier Types for LI_T3
|
Identifier type |
Owner |
ETSI TS 103 221-1 [7] TargetIdentifier type |
Definition |
|
AKID |
3GPP |
TargetIdentifierExtension / AKID |
AKID (see XSD schema) |
When the IRI POI present in the AF detects that a UE has requested the use of a targeted A-KID, it shall continue to generate xIRI events for that A-KID until it detects that the UE has requested the use of a different A-KID, at which point it shall implicitly deactivate the previous Task. In addition, the AAnF may at any time issue a DeactivateTask message against the Task, at which point the AF shall cease interception of the A-KID and remove the Task as per ETSI TS 103 221-1 [7] clause 6.2.3.
7.9.1.3 Generation of xIRI at IRI-POI in AAnF over LI_X2
7.9.1.3.1 General
The IRI-POI present in the AAnF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.3.1, the details of which are described in the following clauses.
7.9.1.3.2 AAnF Anchor Key Register
The IRI-POI in the AAnF shall generate an xIRI containing an AAnFAnchorKeyRegister record when the IRI-POI present in the AAnF detects reception of an AKMA-context, i.e. an (A-KID, KAKMA)-pair associated with a target, from the AUSF, see TS 33.535 [65] clause 7.1.2.
Table 7.9.1.3-1: AAnFAnchorKeyRegister record
|
Field name |
Value |
M/C/O |
|
aKID |
AKMA Anchor Key Identifier (see TS 33.535 [65] clause 4.4.2). |
M |
|
SUPI |
SUPI associated with the A-KID. |
M |
|
kAKMA |
AKMA Anchor Key (see TS 33.535 [65] clause 5.1). Shall be included if available NOTE: Whether kAKMA is included could also depend on whether provisioning is general or service specific. |
C |
7.9.1.3.3 AAnF AKMA application key get
The IRI-POI in the AAnF shall generate an xIRI containing an AAnFAKMAApplicationKeyGet record when the IRI-POI present in the AAnF detects an AKMA application key get from an AF (directly or via NEF), see TS 33.535 [65], clauses 7.1.3 and 7.3.1.
Table 7.9.1.3-2: AAnFKAKMAApplicationKeyGet record
|
Field name |
Value |
M/C/O |
|
Type |
Indicates whether the AF requesting the key is internal to the network or external. |
M |
|
aKID |
AKMA Anchor Key Identifier. |
M |
|
keyInfo |
Key information for the requested derived AF-specific key (see table 7.9.1.3-3). |
M |
Table 7.9.1.3-3: AFKeyInfo structure
|
Field name |
Value |
M/C/O |
|
aFID |
AKMA AF identifier of the AF associated with the derived AF-specific key. |
M |
|
kAF |
Derived AF-specific key (see TS 33.535 [65] clauses 5.1 and A.4). |
M |
|
kAFExpTime |
Expiry time associated with the derived AF-specific key. |
M |
7.9.1.3.4 AAnF Start of intercept with established AKMA key material
The IRI-POI in the AAnF shall generate an xIRI containing an AAnFStartOfInterceptWithEstablishedAKMAKeyMaterial record when the IRI-POI present in the AAnF detects that interception is activated on a target UE that has already established AKMA key material.
Table 7.9.1.3-4: AAnFStartOfInterceptWithEstablishedAKMAKeyMaterial record
|
Field name |
Value |
M/C/O |
|
aKID |
AKMA Anchor Key Identifier (currently valid). |
M |
|
kAKMA |
AKMA Anchor Key associated with aKID. |
C |
|
aFKeyList |
List of all available (aFID, kAF, kAFExpTime)-tuples which are available, have not expired and complies with provisioning. |
C |
7.9.1.3.5 AAnF AKMA context removal
The IRI-POI in the AAnF shall generate an xIRI containing an AAnFAKMAContextRemovalRecord when the IRI-POI present in the AAnF receives a request from an NF to delete AKMA context, see TS 33.535 [65] clause 7.1.4.
Table 7.9.1.3-5: AAnFAKMAContextRemovalRecord record
|
Field name |
Value |
M/C/O |
|
aKID |
AKMA Anchor Key Identifier. |
M |
|
nFInstanceID |
Identity of NF originating the request encoded as per TS 29.571 [17] clause 5.3.2. |
M |
7.9.1.4 Generation of xIRI at IRI-POI in generic SUPI-based AF using over LI_X2
7.9.1.4.1 General
The IRI-POI present in the AF shall send the xIRIs over LI_X2 for each of the events listed in TS 33.127 [5] clause 7.9.3.1, the details of which are described in the following clauses.
7.9.1.4.2 AF Application key refresh
The IRI-POI in the AF shall generate an xIRI containing an AFAKMApplicationKeyRefresh record when the IRI-POI present in the AF detects that a KAF-key previously obtained from an AAnF is being locally refreshed by the Ua* security protocol in use, see TS 33.535 [65] clause 6.4.3.
Table 7.9.1.4-1: AFAKMAApplicationKeyRefresh record
|
Field name |
Value |
M/C/O |
|
aFID |
AKMA AF identifier. |
M |
|
aKID |
AKMA Anchor Key Identifier. |
M |
|
kAF |
New value of the AF-specific key, after refresh. |
M |
|
uaStarParams |
Set of new Ua* security protocol parameters associated with kAF, if updated. |
C |
7.9.1.4.3 AF Start of intercept with established AKMA application key
The IRI-POI in the AF shall generate an xIRI containing an AFStartOfInterceptWithEstablishedAKMAApplicationKey record when the IRI-POI present in the AF detects interception is being triggered on a target UE that has already established AKMA application key.
Table 7.9.1.4-2: AFStartOfInterceptWithEstablishedAKMAApplicationKey record
|
Field name |
Value |
M/C/O |
|
aFFQDN |
FQDN-part of AKMA AF identifier. |
M |
|
aKID |
AKMA Anchor Key Identifier. |
M |
|
kAFParamList |
List of all available all AFSecurityParams (see table 7.9.1.4-3) which have not expired and where the Ua* security protocol parameters corresponds to the set of security parameters used on the Ua* security protocol instance associated with KAF, see TS 33.127 [5] clause 7.9.3.1.5. NOTE: At least one such tuple exists when this event occurs. |
M |
Table 7.9.1.4-3: AFSecurityParams structure
|
Field name |
Value |
M/C/O |
|
aFID |
AF identifier. |
M |
|
aKID |
AKMA Anchor Key Identifier. |
M |
|
kAF |
AKMA derived AF-specific key associated with aKID and Ua* security protocol. |
M |
|
uaStarParams |
Set of Ua* security protocol parameters after complete establishment/update. NOTE: Generic and TLS 1.2 [66] specific formats are provided in Annex A. |
M |
7.9.1.4.4 AF Auxiliary security parameter establishment
The IRI-POI in the AF shall generate an xIRI containing an AFAuxiliarySecurityParameterEstablishment record when the IRI-POI present in the AF detects that security parameters for the Ua* security protocol in use have been established with the target UE, or, when they have been updated without the associated AKMA application key having been refreshed according to clause 7.9.1.4.3.
Table 7.9.1.4-4: AFAuxiliarySecurityParameterEstablishment record
|
Field name |
Value |
M/C/O |
|
aFSecurityParams |
Auxiliary security parameters established (see table 7.9.1.4-3). |
M |
7.9.1.4.5 AF Application key removal
The IRI-POI in the AF shall generate an xIRI containing an AFApplicationKeyRemoval record when the IRI-POI present in the AF detects that an AKMA-derived AF-specific key is deleted or otherwise decommissioned.
Table 7.9.1.4-5: AFApplicationKeyRemoval record
|
Field name |
Value |
M/C/O |
|
aFID |
AF identifier. |
M |
|
aKID |
AKMA Anchor Key Identifier associated with removed key. |
M |
|
removalCause |
Reason for the removal of the application key. |
M |
7.9.1.5 Generation of IRI over LI_HI2
When an xIRI is received over LI_X2 from the IRI-POI in the AAnF or AF, the MDF2 shall send the IRI message over LI_HI2 without undue delay. The IRI message shall contain a copy of the relevant record received from LI_X2. The record may be enriched by other information available at the MDF.
The timestamp field of the ETSI TS 102 232-1 [9] PSHeader structure shall be set to the time at which the AAnF/AF event was observed (i.e. the timestamp field of the xIRI).
Table 7.9.1.5-1 shows the IRI type (see ETSI TS 102 232-1 [9] clause 5.2.10) to be used for each record type.
Table 7.9.1.5-1: IRI type for AAnF originated messages
|
Record type |
IRI Type |
|
AAnFAnchorKeyRegister |
BEGIN |
|
AAnFKAKMAApplicationKeyGet |
CONTINUE |
|
AAnFStartOfInterceptWithEstablishedAKMAKeyMaterial |
BEGIN |
|
AAnFAKMAContextRemovalRecord |
END |
IRI messages associated with the same AKID from the same AAnF shall be assigned the same CIN.
Table 7.9.1.5-2: IRI type for AF originated messages
|
Record type |
IRI Type |
|
AFAKMAApplicationKeyGet |
BEGIN |
|
AFAKMAApplicationKeyRefresh |
CONTINUE |
|
AFStartOfInterceptWithEstablishedAKMAApplicationKey |
BEGIN |
|
AFAuxiliarySecurityParameterEstablishment |
CONTINUE |
|
AFApplicationKeyRemoval |
END |
IRI messages associated with the same AKID from the same AF shall be assigned the same CIN.