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.127  Word version:  18.8.0

Top   Top   Up   Prev   Next
0…   5…   5.4…   5.6…   5.7…   6…   6.2.2…   6.2.3…   6.2.5…   6.3…   6.3.3…   6.3.4…   6.4…   7…   7.3…   7.4…   7.4.7…   7.5…   7.6…   7.7…   7.8…   7.9…   7.10…   7.11…   7.12…   7.13…   7.14…   7.15…   7.16…   8…   A…   A.2…   A.3…   A.4…   B…   D…   E… 
7.15 LI for services encrypted by CSP-provided keys  7.15.1 Background  7.15.1.1 General  7.15.1.2 LI requirements - overview  7.15.2 Architecture  7.15.3 LI for specific services  7.15.3.1 LI for general AKMA-based service  7.15.3.1.1 Background  7.15.3.1.2 LI architecture  7.15.3.1.3 Target identities  7.15.3.1.3.1 Provisioning  7.15.3.1.3.2 Triggering  7.15.3.1.4 IRI events  7.15.3.1.5 Common IRI parameters  7.15.3.1.6 Specific IRI parameters  7.15.3.1.7 Network topologies  7.15.3.1.8 Provision of CC 
...

 

7.15  LI for services encrypted by CSP-provided keys  p. 134

7.15.1  Background  p. 134

7.15.1.1  General  p. 134

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, whereas 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 and also by legacy frameworks such as the Generic Bootstrapping Architecture (GBA), TS 33.220, which is currently undergoing specification for use in the 5GS.
Up

7.15.1.2  LI requirements - overview  p. 134

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 communication 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 identifier space which is independent from the 5G identifiers used for LI provisioning. 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 applicability 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.
To summarize, with respect to the LI at KSF and STF, three specific types of xIRIs are identified:
  1. xIRI from KSF consisting of key management information such as decryption keys and thereto related information.
  2. xIRI from STF consisting of other encryption related parameters, referred to as auxiliary security parameters.
  3. xIRI from STF which are application specific but not pertaining to encryption.
Up

7.15.2  Architecture  p. 135

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.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 7.15.2-1: General architecture, STF using 5G native identifiers.
Figure 7.15.2-1: General architecture, STF using 5G native identifiers.
(⇒ copy of original 3GPP image)
Up
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.
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 7.15.2-2: General architecture, STF not relying on 5G native identifiers.
Figure 7.15.2-2: General architecture, STF not relying on 5G native identifiers.
(⇒ copy of original 3GPP image)
Up
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 KLI 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 communication 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.
Up

7.15.3  LI for specific services  p. 137

7.15.3.1  LI for general AKMA-based service  p. 137

7.15.3.1.1  Background  p. 137
In the specific case of AKMA (see TS 33.535), 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 KAKMA. The Anchor Key Identifier (A-KID) is used to identify the key KAKMA. A-KID can by TS 33.535 be assumed to be globally unique. The AAnF derives, from the anchor key, one or more application-dependent keys referred to as KAF and provides the same to the AF.
The A-KID (and the associated KAKMA) 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.
Up
7.15.3.1.2  LI architecture  p. 137
Copy of original 3GPP image for 3GPP TS 33.127, Fig. 7.15.3.1-1: General AKMA LI Architecture
Figure 7.15.3.1-1: General AKMA LI Architecture
(⇒ copy of original 3GPP image)
Up
Function in the general architecture of 7.15.2 Corresponding AKMA function Reference
KSFAAnFClause 4.2.1 of TS 33.535
STFAFClause 4.2.2 of TS 33.535
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 (KAKMA and/or KAF) 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 and currently cross-reference protocols defined in TS 33.222.
IRI-parameter in the general architecture of 7.15.2 Corresponding AKMA IRI Reference
KLIKAKMA and/or KAF Clause 6.1, 6.2 of TS 33.535
Key identifier, KIDA-KID Clause 4.4.2 of TS 33.535
auxiliary security parametersUa* security protocol parameters Clause 4.4.1 of TS 33.535
Up
7.15.3.1.3  Target identities  p. 138
7.15.3.1.3.1  Provisioning  p. 138
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.
Provisioning of AKMA AF, as an alternative to the triggering described in clause 7.15.3.1.3.2, could be possible for certain types of AFs. This is however service specific and outside the scope of the present document.
7.15.3.1.3.2  Triggering  p. 139
AFs making use of AKMA can use either SUPI or some other form of identifier as basis for providing their services. The AAnF maintains a mapping from valid AKMA key identifiers (A-KID) to the SUPI.
When the IRI-TF in the AAnF receives an A-KID, it shall use said mapping to determine whether or not to trigger the IRI-POI in the AF. Thus, this is done independently of the type of subscriber identifier used locally at the AF.
CC intercept and CC-TF behaviour is service specific and outside the scope of the present document. Non-service-specific CC intercept can be achieved as described in clause 7.15.3.1.8.
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.
Up
7.15.3.1.4  IRI events  p. 139
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 KAF 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 KAF.
  • 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 KAF.
Up
7.15.3.1.5  Common IRI parameters  p. 139
All xIRI shall include at least the following information:
  • Target identity.
  • Additional identities associated with the target as observed by the IRI-POI.
  • Time stamp.
  • Correlation information.
7.15.3.1.6  Specific IRI parameters  p. 140
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.
  • The AKMA anchor key KAKMA itself as defined in TS 33.535, 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.
  • A-KID.
  • KAF, the Application Function specific key delivered to the requesting application function, as defined in TS 33.535.
  • KAF Expiration Time, the expiry time of KAF, as defined in TS 33.535.
  • The Start of intercept with established AKMA key material shall include: A-KID (currently valid).
  • The AKMA anchor key KAKMA associated with currently valid A-KID, unless provisioning has been made service- or AF-specific.
  • The set of all (AKMA AF_ID, KAF, KAF 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
    • KAF 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 KAF.
  • The set of "Ua* security protocol parameters", if updated alongside KAF.
  • Start of intercept with established AKMA application key: The FQDN part of the AKMA AF_ID.
  • A-KID (currently valid).
  • The set of all (A-KID, KAF, KAF 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 / KAF.
Auxiliary security parameter establishment:
  • AKMA AF_ID.
  • A-KID associated with the "Ua* security protocol parameters" being established or updated (i.e. with KAF).
  • KAF 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 KAF) 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 KAF 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.
Up
7.15.3.1.7  Network topologies  p. 141
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.
7.15.3.1.8  Provision of CC  p. 141
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.
Up

Up   Top   ToC