ETSI TS 133 535 V18.8.0 (2025-07)

5G; Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS) (3GPP TS 33.535 version 18.8.0 Release 18)

RTS/TSGS-0333535vi80

General Information

• Status: Not Published
• Technical Committee: 3GPP SA 3 - Security
• Current Stage: 12 - Citation in the OJ (auto-insert)
• Completion Date: 29-Jul-2025

Standards Content (Sample)

TECHNICAL SPECIFICATION
5G;
Authentication and Key Management for Applications (AKMA)
based on 3GPP credentials in the 5G System (5GS)
(3GPP TS 33.535 version 18.8.0 Release 18)

3GPP TS 33.535 version 18.8.0 Release 18 1 ETSI TS 133 535 V18.8.0 (2025-07)

Reference
RTS/TSGS-0333535vi80
Keywords
5G
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 2 ETSI TS 133 535 V18.8.0 (2025-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found at 3GPP to ETSI numbering cross-referencing.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 3 ETSI TS 133 535 V18.8.0 (2025-07)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 6
1 Scope . 8
2 References . 8
3 Definitions of terms, symbols and abbreviations . 9
3.1 Terms . 9
3.2 Symbols . 9
3.3 Abbreviations . 9
4 Architecture for AKMA . 9
4.1 Reference model . 9
4.2 Network elements . 10
4.2.1 AAnF . 10
4.2.2 AF . 11
4.2.3 NEF . 11
4.2.4 AUSF . 11
4.2.5 UDM . 11
4.3 AKMA Service Based Interfaces(SBIs) . 11
4.3.0 General . 11
4.3.1 Void . 11
4.4 Security requirements and principles for AKMA . 12
4.4.0 General . 12
4.4.1 Requirements on Ua* reference point . 12
4.4.2 Requirements on AKMA Key Identifier (A-KID) . 12
4.4.3 Requirements on the UE . 12
4.5 AKMA reference points . 13
4.6 Roaming . 13
4.6.1 AKMA roaming requirements . 13
4.7 Use of Authentication Proxy (AP) . 13
4.7.1 Architecture of using AP . 13
4.7.2 AP-AS reference point . 14
4.7.3 Example of using AP for TLS tunnels . 15
5 Key management . 15
5.1 AKMA key hierarchy . 15
5.2 AKMA key lifetimes . 16
6 AKMA Procedures . 16
6.1 Deriving AKMA key after primary authentication . 16
6.2 Deriving AKMA Application Key for a specific AF . 18
6.2.1 AAnF response with UE Identity . 18
6.2.2 AAnF response without UE Identity . 19
6.3 AKMA Application Key request via NEF . 20
6.4 AKMA key change . 21
6.4.1 K re-keying . 21
AKMA
6.4.2 K re-keying . 21
AF
6.4.3 K refresh . 21
AF
6.4.4 K refresh . 21
AKMA
6.5 Initiation of AKMA . 21
6.6 AAnF AKMA context removal . 22
6.6.1 General . 22
6.7 AAnF Discovery and Selection . 23
6.8 Notification about AKMA service disabling . 23
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 4 ETSI TS 133 535 V18.8.0 (2025-07)
6.8.1 Notification to internal AF about AKMA service disabling . 23
6.8.2 Notification to external AF about AKMA service disabling . 25
7 Security related services . 26
7.1 Services provided by AAnF . 26
7.1.1 General . 26
7.1.2 Naanf_AKMA_AnchorKey_Register service operation . 26
7.1.3 Naanf_AKMA_ApplicationKey_Get service operation . 26
7.1.4 Naanf_AKMA_Context_Remove operation . 26
7.1.5 Naanf_AKMA_ApplicationKey_AnonUser_Getservice operation . 27
7.1.6 Naanf_AKMA_ServiceDisableNotification service operation . 27
7.2 Void . 27
7.3 Services provided by NEF . 27
7.3.1 General . 27
7.3.2 Nnef_AKMA_ApplicationKey_Get service operation . 27
7.3.3 Nnef_AKMA_ServiceDisableNotification service operation . 28
7.4 Services provided by UDM . 28
Annex A (normative): Key derivation functions . 29
A.1 KDF interface and input parameter construction . 29
A.1.1 General . 29
A.1.2 FC value allocations . 29
A.2 K derivation function . 29
AKMA
A.3 A-TID derivation function . . 29
A.4 K derivation function . 30
AF
B.1 TLS based protocols . 31
B.1.1 General . 31
B.1.2 Shared key-based UE authentication with certificate-based AF authentication . 31
B.1.2.1 General . 31
B.1.2.2 Procedures. 31
B.1.3 Shared key-based mutual authentication between UE and AF . 31
B.1.3.1 General . 31
B.1.3.2 Procedures. 32
B.1.3.2.1 Procedures for TLS 1.2 . 32
B.1.3.2.2 Procedures for TLS 1.3 . 32
Annex C (normative): AKMA Ua* protocol based on DTLS . 33
C.1 General . 33
C.1.1 Requirement on the UE . 33
C.1.2 Requirement on the AF . 33
C.2 Shared key-based mutual authentication between UE and AF. 33
C.2.1 General . 33
C.2.2 Procedures for DTLS 1.3 . 33
Annex D (normative): Ua* security protocol: Object Security for Constrained RESTful
Environments (OSCORE) . 34
D.1 General . 34
D.2 Requirements . 34
D.2.1 General . 34
D.2.2 Requirements on the UE . 34
D.2.3 Requirements on the AF . 34
D.2.4 Requirements on the OSCORE . 34
D.3 IETF OSCORE as an AKMA Ua* protocol. 34
D.3.1 General . 34
D.3.2 Procedures . 34
D.3.3 OSCORE Security context . 35
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 5 ETSI TS 133 535 V18.8.0 (2025-07)
D.3.4 Refresh of OSCORE key material . 35
D.3.5 OSCORE Ua* protocol payload encoding . 36
Annex E (informative): Change history . 37
History . 40

ETSI
3GPP TS 33.535 version 18.8.0 Release 18 6 ETSI TS 133 535 V18.8.0 (2025-07)
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
In the present document, modal verbs have the following meanings:
shall indicates a mandatory requirement to do something
shall not indicates an interdiction (prohibition) to do something
The constructions "shall" and "shall not" are confined to the context of normative provisions, and do not appear in
Technical Reports.
The constructions "must" and "must not" are not used as substitutes for "shall" and "shall not". Their use is avoided
insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced,
non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a
referenced document.
should indicates a recommendation to do something
should not indicates a recommendation not to do something
may indicates permission to do something
need not indicates permission not to do something
The construction "may not" is ambiguous and is not used in normative elements. The unambiguous constructions
"might not" or "shall not" are used instead, depending upon the meaning intended.
can indicates that something is possible
cannot indicates that something is impossible
The constructions "can" and "cannot" are not substitutes for "may" and "need not".
will indicates that something is certain or expected to happen as a result of action taken by an agency
the behaviour of which is outside the scope of the present document
will not indicates that something is certain or expected not to happen as a result of action taken by an
agency the behaviour of which is outside the scope of the present document
might indicates a likelihood that something will happen as a result of action taken by some agency the
behaviour of which is outside the scope of the present document
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 7 ETSI TS 133 535 V18.8.0 (2025-07)
might not indicates a likelihood that something will not happen as a result of action taken by some agency
the behaviour of which is outside the scope of the present document
In addition:
is (or any other verb in the indicative mood) indicates a statement of fact
is not (or any other negative verb in the indicative mood) indicates a statement of fact
The constructions "is" and "is not" do not indicate requirements.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 8 ETSI TS 133 535 V18.8.0 (2025-07)
1 Scope
The present document specifies the security features and mechanisms to support authentication and key management
aspects for applications based on subscription credential(s) in 5G system as defined in TS 33.501 [2].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 33.501: "Security architecture and procedures for 5G system".
[3] 3GPP TS 23.501: "System Architecture for the 5G System".
[4] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping
Architecture (GBA)".
[5] 3GPP TS 23.222: "Common API Framework for 3GPP Northbound APIs".
[6] IETF RFC 7542: "The Network Access Identifier".
[7] 3GPP TS 33.222: " Generic Authentication Architecture (GAA); Access to network application
functions using HypertextTransfer Protocol over Transport Layer Security (HTTPS)".
[8] Void
[9] 3GPP TS 23.003: "Numbering, addressing and identification".
[10] IETF RFC 9110: "HTTP Semantics".
[11] 3GPP TS 29.503: "5G System; Unified Data Management Services ".
[12] IETF RFC 9147: "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"
[13] 3GPP TS 33.210: "3G Security; Network Domain Security; IP network layer security".
[14] IETF RFC 8613: "Object Security for Constrained RESTful Environments (OSCORE)".
[15] IETF RFC 8949: "Concise Binary Object Representation (CBOR)".
[16] IETF RFC 5869: "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)".
[17] 3GPP TS 23.502: "Procedures for the 5G System".
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 9 ETSI TS 133 535 V18.8.0 (2025-07)
3 Definitions of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in TR 21.905 [1] and the following apply. A term defined in
the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 [1].
AKMA subscription data: The data in the home operator's network indicating whether or not the subscriber is allowed
to use AKMA.
AKMA context: A set of parameters stored in AAnF, including SUPI, GPSI, K ,A-KID and K expiration time.
AKMA AF
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
3GPP TR 21.905 [1].
A-KID AKMA Key IDentifier
A-TID AKMA Temporary UE IDentifier
AAnF AKMA Anchor Function
AF Application Function
AF_ID AF Identifier
AKMA Authentication and Key Management for Applications
AMF Access and Mobility Management Function
AUSF AUthentication Server Function
CBOR Concise Binary Object Representation
CoAP Constrained Application Protocol
K AKMA Application Key
AF
K AKMA Anchor Key
AKMA
KDF Key Derivation Function
NEF Network Exposure Function
OSCORE Object Security for Constrained RESTful Environments
RID Routing InDicator
UDM Unified Data Management
4 Architecture for AKMA
4.1 Reference model
Figure 4.1-1 shows a fundamental network model of AKMA, as well as the interfaces between them.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 10 ETSI TS 133 535 V18.8.0 (2025-07)
UDM
NEF AAnF
Nnef Naanf
Nudm
Nausf Namf
AUSF AMF AF
N2
(R)AN UE
Figure 4.1-1: Fundamental Network Model for AKMA
NOTE: Figure 4.1-1 shows the case where AAnF is deployed as a standalone function. Deployments can choose
to collocate AAnF with AUSF or with NEF according to operators' deployment scenarios.
Figure 4.1-2 shows the AKMA architecture using the reference point representation.
UDM UDM
N13 N13
N61 N62
N61
AAnF AAnF
AUSF AF AUSF AF
N12 N12
N63
N33
AMF AMF
Ua* Ua*
NEF
N1
N1
N2 N2
(R)AN UE (R)AN UE
(a)
(b)
Figure 4.1-2: AKMA Architecture in reference point representation for (a) internal AFs of HPLMN and
(b) external AFs
The AKMA service requires a new logical entity, called the AKMA Anchor Function (AAnF).
The AKMA Architecture in Figure 4.1-2 is applicable to both roaming scenario and non-roaming scenario:
- non-roaming: UE is in HPLMN and accessing an AF;
- roaming scenario#1: UE is in VPLMN and accessing an internal HPLMN AF;
- roaming scenario#2: UE is in VPLMN and accessing an internal VPLMN AF;
- roaming scenario#3: UE is in VPLMN and accessing an external AF in the Data Network.
4.2 Network elements
4.2.1 AAnF
The AAnF is the anchor function in the HPLMN. The AAnF stores the AKMA Anchor Key (K ), A-KID and
AKMA
SUPI/GPSI for AKMA service, which is received from the AUSF/UDM after the UE completes a successful 5G
primary authentication. The AAnF also generates the key material to be used between the UE and the Application
Function (AF) and maintains UE AKMA contexts. The AAnF sends SUPI/GPSI of the UE to AF located inside the
operator's network according to the AF request or sends SUPI to NEF. If GPSI is required, the AAnF retrieves the GPSI
from UDM based on available SUPI. The AAnF has the capability to trigger a primary authentication for K
AKMA
refreshing purpose.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 11 ETSI TS 133 535 V18.8.0 (2025-07)
4.2.2 AF
The AF is defined in TS 23.501 [3] with additional functions:
- AF with the AKMA service enabling requests for AKMA Application Key, called K from the AAnF using A-
AF,
KID.
- AF shall be authenticated and authorized by the operator network before providing the K to the AF.
AF
- The AF located inside the operator's network performs the AAnF selection.
4.2.3 NEF
The NEF is defined in TS 23.501 [3] with additional functions:
- The NEF enables and authorizes the external AF assessing AKMA service and forwards the request towards the
AAnF.
- The NEF performs the AAnF selection.
4.2.4 AUSF
The AUSF is defined in TS 23.501 [3] with additional functions:
- AUSF provides the SUPI and AKMA key material (A-KID, K ) of the UE to the AAnF.
AKMA
- AUSF performs the AAnF selection.
4.2.5 UDM
The UDM is defined in TS 23.501 [3] with the additional functions:
- UDM stores AKMA subscription data of the subscriber and provides AKMA indication and RID to AUSF.
- UDM triggers primary authentication to refresh K .
AKMA
4.3 AKMA Service Based Interfaces(SBIs)
4.3.0 General
The following interfaces are involved in AKMA network architecture:
- Nnef: Service-based interface exhibited by NEF.
- Nudm: Service-based interface exhibited by UDM.
NOTE 1: UDM services related to AKMA service are defined in TS 33.501 [2] clauses 14.2.2, 14.2.6, TS 23.502
[17] clauses 5.2.3.3.2, 5.2.3.5.2.
- Naanf: Service-based interface exhibited by AAnF.
The AAnF interacts with the AUSF and the AF using Service-based Interfaces. When the AF is located in the operator's
network, the AAnF shall use Service-Based Interface to communicate with the AF directly. When the AF is located
outside the operator's network, the NEF shall be used to exchange the messages between the AF and the AAnF.
4.3.1 Void
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 12 ETSI TS 133 535 V18.8.0 (2025-07)
4.4 Security requirements and principles for AKMA
4.4.0 General
The following security requirements are applicable to AKMA:
- AKMA shall reuse the same UE subscription and the same credentials used for 5G access.
- AKMA shall reuse the 5G primary authentication procedure and methods specified in TS 33.501 [2] for the sake
of implicit authentication for AKMA services.
- The SBA interface between the AAnF and the AUSF shall be confidentiality, integrity and replay protected.
- The SBA interface between AAnF and AF/NEF shall be confidentiality, integrity and replay protected.
- The SBA interface between AAnF and UDM shall be confidentiality, integrity and replay protected.
- The AKMA Application Key (K ) shall be provided with a maximum lifetime based on the operator’s local
AF
authentication policy.
NOTE: Void
4.4.1 Requirements on Ua* reference point
The Ua* reference point is application specific. The generic requirements for Ua* are:
- Ua* protocol shall be able to carry AKMA Key Identifier (A-KID) .
- The UE and the AKMA AF shall be able to secure the reference point Ua* using the AKMA Application Key
derived from the AKMA Anchor Key.
NOTE 1: The exact method of securing the reference point Ua* depends on the application protocol used over
reference point Ua*.
NOTE 2: Void
- The Ua* protocol shall be able to handle the expiration of K
AF.
4.4.2 Requirements on AKMA Key Identifier (A-KID)
Requirements for AKMA Key Identifier (A-KID) are:
- A-KID shall be globally unique.
- A-KID shall be usable as a key identifier in protocols used in the reference point Ua*.
- AKMA AF shall be able to identify the AAnF serving the UE from the A-KID.
4.4.3 Requirements on the UE
The requirements on the UE are:
- Applications on the UE shall not be able to get access to K
AKMA.
- An application on the UE shall only get the KAF keys related to specific AF Identifiers (AF_IDs) that the
application is authorized to get.
- An application on the UE shall not be able to get access to the K keys that belong to other applications.
AF
NOTE: How these requirements are satisfied is out of scope of 3GPP.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 13 ETSI TS 133 535 V18.8.0 (2025-07)
4.5 AKMA reference points
The AKMA architecture reuses the following reference point from the 5GC for the execution of the primary
authentication procedure:
N1: Reference point between the UE and the AMF.
N2: Reference point between the (R)AN and the AMF.
N12: Reference point between AMF and AUSF.
N13: Reference point between the UDM and the AUSF.
N33: Reference point between NEF and an external AF.
The AKMA architecture defines the following reference points:
N61: Reference point between the AAnF and the AUSF.
N62: Reference point between the AAnF and an internal AF.
N63: Reference point between the AAnF and NEF.
Ua*: Reference point between the UE and an AF.
NOTE: The reference point Ua* carries the application protocol, which is secured using the key material agreed
between UE and AAnF as a result of successful AKMA procedures.
4.6 Roaming
4.6.1 AKMA roaming requirements
Requirements for AKMA roaming are:
- The roaming subscriber shall be able to utilize the AKMA feature provided by the home network.
- The home network shall be able to control whether its subscriber is authorized to use the service in the visited
network.
4.7 Use of Authentication Proxy (AP)
4.7.1 Architecture of using AP
An Authentication Proxy (AP) is a proxy which takes the role of an AF and delegates a group of Application Servers
(ASs). It may reside between the UE and the AS as depicted in the figures below. The AP helps the ASs behind the AP
to execute AKMA procedures to save the consumption of signalling resources and AAnF computing resources. It may
also relieve the AS of security tasks. The use of an AP is fully compatible with the architecture specified in the present
document.
The AP can assure the ASs that the request is coming from an authorized subscriber of the MNO.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 14 ETSI TS 133 535 V18.8.0 (2025-07)

AS1
AP-AS
N62
AP-AS
AAnF
AP
AS2
AP-AS
…
Ua*
ASn
UE
Figure 4.7.1-1: Environment and reference points of AP when AP is internal

NEF
AS1
AP-AS
N33
N63
AP-AS
AAnF
AP
AS2
AP-AS
…
Ua*
ASn
UE
Figure 4.7.1-2: Environment and reference points of AP when AP is external
If the Ua* is HTTP based, the UE is configured with the FQDN of AS, and the AP is a reverse proxy to handle the
communication between the UE and the AS. The AP takes the role of an AF. The AKMA Application Key (i.e. K ),
AF
which is utilized between the UE and the AP, is derived based on the FQDN of the AS.
If the Ua* is not HTTP based, it is left to implementation, e.g., how the AP identifies the traffic towards corresponding
AS may be pre-configured in the AP by the operator who deploys the AP.
4.7.2 AP-AS reference point
The HTTP protocol is run over the AP-AS reference point.
Confidentiality and integrity protection can be provided for the reference point between the AP and the AS using
NDS/IP mechanisms as specified in TS 33.210 [13]. For traffic between different security domains, the Za reference
point shall be operated. For traffic inside a security domain, it is up to the operator to decide whether to deploy the Zb
reference point.
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 15 ETSI TS 133 535 V18.8.0 (2025-07)
4.7.3 Example of using AP for TLS tunnels
When the TLS based protocol is used as Ua* profile, the AP can be used to handle the TLS security relation with the
UE and relieves the AS of this task. When an HTTPS request is destined towards an AS behind an AP, the AP
terminates the TLS tunnel and performs UE authentication. The AP proxies the HTTP requests received from UE to one
or many application servers. The AP may add an assertion of identity of the subscriber for use by the AS, when the AP
forwards the request from the UE to the AS.

AS1
AP-AS
N62
AP-AS
AAnF
AP
AS2
TLS
AP-AS
…
Ua* tunnel
ASn
UE
Figure 4.7.3-1: Environment and reference points of AP for TLS tunnels when AP is internal

NEF
AS1
AP-AS
N33
N63
AP-AS
AAnF
AP
AS2
TLS
AP-AS
…
Ua* tunnel
ASn
UE
Figure 4.7.3-2: Environment and reference points of AP for TLS tunnels when AP is external

5 Key management
5.1 AKMA key hierarchy
The key hierarchy (see Figure 5.1-1) includes the following keys: K , K , K K is generated by AUSF as
AUSF AKMA AF. AUSF
specified in clause 6.1 of TS 33.501 [2].
ETSI
3GPP TS 33.535 version 18.8.0 Release 18 16 ETSI TS 133 535 V18.8.0 (2025-07)
Keys for AAnF:
- K is a key derived by ME and AUSF from K .
AKMA AUSF
Keys for AF:
- K is a key derived by ME and AAnF from K .
AF AKMA
KAKMA is derived according to the procedures of clause 6.1.
K is derived according to the procedures of clauses 6.2 or 6.3.
AF
Successful 5G Primary Authentication
as specified in TS 33.501 [2]
KAUSF
AUSF ME
HPLMN
K
AKMA
ME
AAnF
K
AF
AF ME
Figure 5.1-1: AKMA Key Hierarchy
5.2 AKMA key lifetimes
The K and A-KID are valid until the next successful primary authentication is performed (implicit lifetime), in
AKMA
which case the K and A-KID are replaced.
AKMA
AKMA Application Keys K shall use explicit lifetimes based on the operator's policy. The lifetime of K shall be
AF AF
sent by the AAnF as described in clauses 6.2 and 6.3. In case that a new AKMA Anchor Key K is established, the
AKMA
AKMA Application Key K can continue to be used for the duration of the current application session or until its
AF
lifetime expires, whichever comes first. When the K lifetime expires, a new AKMA Application Key is established
AF
based on the current AKMA Anchor Key K .
AKMA
NOTE: When the K lifetime expires and the K has not changed in AAnF, according to the Annex A.4, the
AF AKMA
AKMA Application Key which is established based on the current AKMA Anchor Key K is not a
AKMA
new one.
6 AKMA Procedures
6.1 Deriving AKMA key after primary authentication
There is no separate authentication of the UE to support AKMA functionality. Instead, AKMA reuses the 5G primary
authentication procedure executed e.g. during the UE Registration to authenticate the UE. A successful 5G primary
authentication results in K being stored at the AUSF and the UE. Figure 6.1-1 shows the procedure to derive K
AUSF AKMA
after a successful primary authentication.

ETSI
3GPP TS 33.535 version 18.8.0 Release 18 17 ETSI TS 133 535 V18.8.0 (2025-07)
UE AMF AUSF UDM AAnF
1. Nudm_UEAuthentication_
Get Request (SUPI/SUCI)
2. Nudm_UEAuthentication_Get
Primary authentication
Response (AV, [AKMA Ind],
[RID])
3a. Generate 3a. Generate
K from K from
AKMA AKMA
K K
AUSF AUSF
3b. Generate 3b. Generate
A-KID A-KID
4.Naanf_AKMA_AnchorKey_Register Request
(SUPI, A-KID, K )
AKMA
5. Naanf_AKMA_AnchorKey_Register
Response
Figure 6.1-1: Deriving K after primary authentication
AKMA
1) During the primary authentication procedure, the AUSF interacts with the UDM in order to fetch authentication
information such as subscription credentials (e.g. AKA Authentication vectors) and the authentication method
using the Nudm_UEAuthentication_Get Request service operation.
2) In the response, the UDM may also indicate to the AUSF whether the AKMA Anchor key needs to be generated
for the UE. If the AKMA indication is included, the UDM shall also include the RID of the UE.
3) If the AUSF receives the AKMA indication from the UDM, the AUSF shall store the K and generate the
AUSF
AKMA Anchor Key (K ) and the A-KID from K
...