7.15 LI for services encrypted by CSP-provided keys

33.1273GPPLawful Interception (LI) architecture and functionsRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.15.1 Background

7.15.1.1 General

3GPP standards have defined frameworks for encrypting application layer traffic based on cryptographic keys derived from USIM (or equivalents such as eSIM). These frameworks can be characterized by a Key Server Function (KSF), located at the home CSP and having a connection to the AAA infrastructure (typically the AUSF). The KSF reuses the basic network layer authentication service (native 5G AKA or EAP-AKA’) to obtain a derived anchor key. From this anchor key, the KSF can derive one or more service specific keys, which can be provided to various application functions. Such an application function provides, besides the application specific functionality, a Security Termination Function (STF) endpoint for the security with the UE. The KSF uses a 5G native identifier space for subscribers such as SUPI , wheras the STF could in principle use any identifier type to identify its users. Additionally, while the KSF is always located in HPLMN, the STF can be located either in HPLMN, in VPLMN, or even outside a PLMN, e.g. at an enterprise.

In 5G context, the principles laid out above are currently realized by the Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System as defined in TS 33.535 [47] and also by legacy frameworks such as the Generic Bootstrapping Architecture (GBA), TS 33.220 [48], which is currently undergoing specification for use in the 5GS.

NOTE : The terms KSF and STF above are defined for use in the present document, and will in general be realised by network functions specific to a given key management protocol or framework. See clause 7.15.3.1.1 for an example of how these terms are mapped to functions defined by the AKMA framework.

7.15.1.2 LI requirements – overview

This clause specifies a common LI architecture for a general CSP-provided key management solution in support of encryption, implemented by generic KSF and STF functionality as defined in clause 7.15.1.1.

When encryption keys are provided by a CSP, lawful interception for a target’s communication may be done in one of the two ways: (i) decrypt intercepted communication traffic before delivering IRIs and CCs to the LEA, or, (ii) provide to the LEA the decryption keys and other information necessary to enable the decryption of communication traffic. To fully enable decryption of communicaiton traffic, LI functions are in general required both at the KSF and at the STF as illustrated by the following examples.

EXAMPLE 1: In most situations, after STF has obtained encryption key from KSF, the STF has all the necessary information to decrypt the communication traffic without the additional help of KSF. In this situation, an LI function within the STF can decrypt the target’s communication and does not need to provide, explicit encryption-related xIRI. However, the STF can also have access to xIRI which is not related to encryption, but which is still application specific, and which also can be of relevance to include as part of IRI.

EXAMPLE 2: In some situations, STF may not know whether communication traffic is that of a target since it could use a user identfier space which is independent from the 5G identifiers used for LI provisiong. In this situation, the LI function in KSF will have to provide intercept triggers to the LI function in the STF in order to identify the target communication traffic. Moreover, even if decrypted xCC is provided by the STF, the KSF can still typically report xIRI relating to key management (e.g. request for keys from other STFs, expiry of keys etc) which are of relevance for LI. For a third example of applicabity of LI at the KSF, refer to NOTE 3 below.

As mentioned, the physical/jurisdictional location of KSF and STF can differ depending on the scenario which can have bearing on LI requirements.

NOTE 1: When a warrant is served to a PLMN that has neither the STF nor the KSF, handling of LI aspects specifically related to the encrypted communication traffic of a target is outside the scope of the present document.

NOTE 2: For roaming situations, where LI providing unencrypted communication in the VPLMN is required, the STF would need to be located in the VPLMN and the STF would also need to use 5G native user identifiers which enable LI provisioning in the VPLMN (since LI can not rely on triggering from HPLMN in this case). However, such roaming scenarios are outside the scope of the present document.

NOTE 3: When a warrant is issued to a HPLMN that has the KSF, but not the STF, then the LI function in that KSF can still provide encryption related keys and related events to the LEMF. LI at the STF is however then outside the scope of the present document.

To summarize, with respect to the LI at KSF and STF, three specific type of xIRIs are identified:

1. xIRI from KSF consting of key managment information such as decryption keys and thereto related information.

2. xIRI from STF consisting of other encryption related parameters, refered to as auxiliary security parameters.

3. xIRI from STF which are application specific but not pertaining to encryption.

7.15.2 Architecture

Figure 7.15.2-1 shows the general LI architecture where an IRI-POI in the KSF provides the xIRIs that include key management related information such as the decryption keys to the MDF2 over the LI_X2 interface. The STF can provide xIRI and xCC for the target’s communication traffic, as described in more detail below. Figure 7.15.2-1 shows the case where STF is assumed to provide services based on 5G-native identifier, e.g. SUPI, enabling the STF to be provisioned over LI_X1.

NOTE: If the STF is located outside the PLMN (not shown), the LI_X2 from IRI-POI in KSF can be used to provide IRI with key management information such as decryption keys via MDF2.

Figure 7.15.2-1: General architecture, STF using 5G native identifiers.

If the STF instead provides services based on some other user identifier space, the STF POIs are assumed to be triggered by IRI-TF and CC-TF in the KSF, as shown in figure 7.15.2-2. The triggering is based on the KSF detecting requests from the STF for cryptographic keys associated with a target UE. When the key management service of the KSF is based on target specific key identifiers (KID) known both at KSF and STF, such KID can serve as basis for mapping STF-identifiers to 5G-native identifiers at the KSF. The IRI-TF or CC-TF present in the KSF send the triggers to the IRI-POI or CC-POI present in the STF to indicate that the communication traffic is that of a target. The IRI-POI and CC-POI are then enabled for delivery of xIRI and the xCC with communication traffic of the target in a decrypted form as laid out above.

Figure 7.15.2-2: General architecture, STF not relying on 5G native identifiers.

The IRI-POI present in the KSF is provisioned by the LIPF over LI_X1 and is responsible for providing key management related information in the form of xIRI. The key management related information can comprise information about requesting, creating, changing, or deleting encryption keys, and most importantly, can comprise decryption keys. Such decryption keys are generically denoted K_LI and may comprise one or more cryptographic keys.

The IRI-POI in the STF is responsible for providing xIRI with auxiliary security parameters necessary to decrypt xCC which has been encrypted using the keys provided by the KSF. In addition, application specific (not encryption related) xIRI for the target’s communication traffic. In more detail, the auxiliary security parameters can typically include:

– Additional cryptographic keys.

– Selected protocols / cipher-suites / cryptographic algorithms for UE-STF traffic encryption.

– Parameters for key derivation (e.g. nonces).

– Other cryptographic state information (e.g. counters).

Similarly, the CC-POI in the STF is responsible for providing the xCC for the target’s communicaiton traffic in a decrypted form.

The remainder of the present clause provides details of IRI-intercept and, as applicable, CC-intercept of specific services encrypted by CSP-provided keys.

7.15.3 LI for specific services

7.15.3.1 LI for general AKMA-based service

7.15.3.1.1 Background

In the specific case of AKMA (see TS 33.535 [47]), the KSF of the general architecture described above corresponds to the AAnF (AKMA Anchor Function). The STF corresponds to the AKMA Application Function (AF), identified by an application identifier AKMA AF_ID. Key requests from external AFs are routed to AAnF via the NEF.

An AKMA Anchor Key is provided to the AAnF and is referred to as K_AKMA.The Anchor Key Identifier (A-KID) is used to identify the key K_AKMA. A-KID can by TS 33.535 [47] be assumed to be globally unique. The AAnF derives, from the anchor key, one or more application-dependent keys referred to as K_AF and provides the same to the AF.

The A-KID (and the associated K_AKMA) of a specific UE can be modified by running 5G primary authentication. The A-KID can also become invalid at the AAnF due to specific AKMA Context Removal request from some duly authorized NF.

7.15.3.1.2 LI architecture

NOTE: If the AF is located outside the PLMN (not shown) the LI_T2 and LI_T3 interfaces are not used but LI_X2 from IRI-POI in AAnF can still be used to provide IRI with key management information such as decryption keys via MDF2.

Figure 7.15.3.1-1: General AKMA LI Architecture

Table 7.15.3.1-1: Mapping functions between the general architecture and AKMA

Function in the general architecture of 7.15.2	Corresponding AKMA function	Reference
KSF	AAnF	TS 33.535 [47] clause 4.2.1
STF	AF	TS 33.535 [47] clause 4.2.2

The LIPF present in the ADMF provisions the IRI-POI present in the AAnF and the MDF2/MDF3 over LI_X1 interfaces. The LIPF may interact with the SIRF (over LI_SI) to find the correct instances of these functions. Depending on the warrant received from LEA, provisioning could be restricted to only specific services/AFs or could be general.

The LIPF also provisions IRI-TF and CC-TF present in the AAnF. The IRI-TF and CC-TF are capable of mapping AKMA key identifiers (A-KID) to/from SUPI. When a UE presents A-KID to the AAnF, via the AF, the IRI-TF and CC-TF present in the AAnF trigger the IRI-POI and CC-POI present in the AF respectively when LI is active on the SUPI associated with the A-KID.

The AAnF only provides xIRI comprising key management events (creation, modification, deletion, etc, of encryption keys), as well as cryptographic keys themselves (K_AKMA and/or K_AF) and key identifiers (A-KID). The AF can provide both xIRI and xCC. The xIRI from the AF can comprise both auxiliary security parameters (Ua* security protocol parameters, see below) and any other application specific information as set out in the general case described in clause 7.15.2.

Providing decrypted xCC depends on details of the security protocol used between the target UE and AF. This protocol is in AKMA referred to as the Ua* security protocol. Below, the generic term "Ua* security protocol parameters" is used to denote the complete set of auxiliary security parameters, besides the AKMA-related key material itself, necessary to decrypt the application traffic.

EXAMPLE: The Ua* security protocol can be a profile of TLS version 1.2.

3GPP-defined Ua* security protocols and protocol identifiers are defined in annex B of TS 33.535 [47] and currently cross-reference protocols defined in TS 33.222 [49].

Table 7.15.3.1-2: Mapping xIRI between the general architecture and AKMA

IRI-parameter in the general architecture of 7.15.2	Corresponding AKMA IRI	Reference
K_LI	K_AKMA and/or K_AF	TS 33.535 [47] clause 6.1, 6.2
Key identifier, KID	A-KID	TS 33.535 [47] clause 4.4.2
auxiliary security parameters	Ua* security protocol parameters	TS 33.535 [47] clause 4.4.1

7.15.3.1.3 Target identities

7.15.3.1.3.1 Provisioning

The LIPF present in the ADMF provisions the intercept information associated with the following target identity to the IRI-POI, IRI-TF and CC-TF present in the AAnF:

– SUPI.

7.15.3.1.3.2 Triggering

To support LI in AKMA AFs not using SUPI identifiers, the triggering functions of the AAnF shall maintain a mapping from valid AKMA key identifiers (A-KID) to the SUPI.

An initial trigger for a new Task shall be issued to POIs of AFs matching the scope of the warrant when an A-KID for a target is first created. Since all such AFs might not be known in advance, this triggering can alternatively be performed dynamically, when a previously unknown AF requests key material related to a specific A-KID, from the AAnF.

Each time the A-KID of a target changes (due to primary authentication), the TF shall issue a new Task to the AF POI containing the new A-KID.

7.15.3.1.4 IRI events

The IRI-POI present in the AAnF shall generate xIRI when it detects the following specific events or information related to an LI target:

– Anchor key register: AAnF receives AKMA-related key material from AUSF. This event can occur each time a target UE performs successful primary authentication to 5GC and then overwrites previous AKMA parameters stored at the AAnF.

– AKMA application key get: AAnF receives request for AKMA-related key material from a network-internal AF, or, from a network-external AF (via NEF).

– Start of intercept with established AKMA key material: AAnF detects that interception is activated on a target UE that has already established AKMA key material.

– AKMA context removal: An NF requests AAnF to remove AKMA-related key material.

The conditions under which the IRI-POI present in the AF generates xIRI is application-specific, but shall include at least the following events relating to xIRI with auxiliary security parameter:

– Application key refresh: AF performs local K_AF refresh with the target UE.

– Start of intercept with established AKMA application key: the AF detects that interception is activated on a target UE that already has an established K_AF.

– Auxiliary security parameter establishment: establishment or update of "Ua* security protocol parameters" between the UE and the AF (e.g. nonces, selected security algorithms, etc.).

– Application key removal: the AF terminates the connection and does not make further use of K_AF.

7.15.3.1.5 Common IRI parameters

All xIRI shall include at least the following information:

– Target identity.

– Additional identities associated with the target as observed by the IRI-POI.

NOTE: This applies mainly for the AF.

– Time stamp.

– Correlation information.

7.15.3.1.6 Specific IRI parameters

Additionally, to the common IRI parameters, the following xIRI shall be provided by the IRI-POI of the AAnF for the specific IRI events.

The Anchor key register shall include:

– A-KID, Anchor key identity of the currently valid anchor key associated with the event, see TS 33.535 [47].

– The AKMA anchor key K_AKMA itself as defined in TS 33.535 [47], unless LI has been provisioned only for specific services or specific AFs.

The AKMA application key get shall include:

– Type: internal or external AF.

– AKMA AF_ID (Application Function Identity), of the requesting application function. AF_ID has format
AF_ID = FQDN of the AF || Ua* security protocol identifier, as defined in TS 33.535 [47].

– A-KID.

– K_AF, the Application Function specific key delivered to the requesting application function, as defined in TS 33.535 [47].

– K_AFExpiration Time, the expiry time of K_AF, as defined in TS 33.535 [47].

NOTE 1: If the TLS-based Ua* security protocols of annex B in TS 33.535 [47] is used between a target UE and STF, it could likely be the case that K_AF itself is insufficient as decryption key for xCC. Further key material only available as part of the "Ua* security protocol parameters" element of xIRI obtained from the STF, see below, are then likely also needed.

– The Start of intercept with established AKMA key material shall include:A-KID (currently valid).

NOTE 2: While a new primary authentication overwrites old AKMA contexts (K_AKMA and A-KID), the expiry time of earlier application specific keys (K_AF), derived from an old AKMA context (with an old A-KID) could still lie in the future when the Start of intercept with established AKMA key material occurs.

– The AKMA anchor key K_AKMA associated with currently valid A-KID, unless provisioning has been made service- or AF-specific.

– The set of all (AKMA AF_ID, K_AF, K_AF Expiration Time)-tuples associated with the target and satisfying all of:

– Being available at AAnF,

– AF_ID is within scope of previous LI-provisioning, and

– K_AF Expiration Time has not yet been passed.

The AKMA context removal xIRI shall include:

– A-KID.

– NF identity, of the NF requesting the removal.

Additionally, to the common IRI parameters, the following xIRI shall be provided by the IRI-POI of an AF for the specific IRI events:

– Application key refresh:AKMA AF_ID.

– A-KID.

– New K_AF.

– The set of "Ua* security protocol parameters", if updated alongside K_AF.

– Start of intercept with established AKMA application key:The FQDN part of the AKMA AF_ID.

NOTE 3: Since a given application function could have several parallel secured sessions with a target UE, the FQDN part of AF_ID is reported separately, while details of each session, e.g. "Ua* security protocol parameters", is reported in the information elements below.

– A-KID (currently valid).

– The set of all (A-KID, K_AF, K_AF expiry, "Ua* security protocol parameters")-tuples where A-KID is associated with the target and satisfying all of:

– Being available in the AF and not having expired, and

– The "Ua* security protocol parameters" are associated with the specific A-KID / K_AF.

Auxiliary security parameter establishment:

– AKMA AF_ID.

– A-KID associated with the "Ua* security protocol parameters" being established or updated (i..e with K_AF).

– K_AF associated with the "Ua* security protocol parameters" being established or updated.

– The actual set of "Ua* security protocol parameters" associated with the event.

Application key removal:

– AKMA AF_ID.

– A-KID.

– Cause (reason for removal, e.g. key expiration).

For both Start of intercept with established application key and Auxiliary security parameter establishment, if other cryptographic key material (besides K_AF) is required to decrypt xCC, then it shall be ensured that all such key material is included as part of "Ua* security protocol parameters".

EXAMPLE: One example when K_AF alone is insufficient is when the Ua* security protocol deploys a separate "base secret" (e.g. from a stand-alone Diffie-Hellman key exchange), which is used by UE/AF when producing traffic encryption keys. In such case, also this base secret is needed for decryption.

7.15.3.1.7 Network topologies

The AAnF shall provide the IRI-POI, IRI-TF, and CC-TF functions, and the network-internal AF shall provide the IRI-POI function in the following network topology cases:

– Non-roaming case.

NOTE: Handling of AKMA-based services in the roaming case is currently not defined in TS 33.535 [47].

7.15.3.1.8 Provision of CC

Since AKMA is a non-service specific framework, interception of (decrypted) xCC at an AF for AKMA-secured services is not specified in further detail as part of clause 7.15.3.1. Non-service specific intercept of encrypted UP traffic could in some cases however be accomplished by combining the IRI-intercept (in particular, intercepted key material) of clauses 7.15.3.1.3 to 7.15.3.1.6 with the general solution for network layer xCC-intercept at the UPF as defined in clause 6.2.3.