v16 5g-Ausf
v16 5g-Ausf
v16 5g-Ausf
0 (2019-06)
Technical Specification
The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP..
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 16 2 3GPP TS 29.509 V16.0.0 (2019-06)
Keywords
3GPP, 5G System
3GPP
Postal address
Internet
http://www.3gpp.org
Copyright Notification
© 2019, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 16 3 3GPP TS 29.509 V16.0.0 (2019-06)
Contents
Foreword............................................................................................................................................................. 7
1 Scope ........................................................................................................................................................ 8
2 References ................................................................................................................................................ 8
3 Definitions and abbreviations................................................................................................................... 9
3.1 Definitions ......................................................................................................................................................... 9
3.2 Abbreviations..................................................................................................................................................... 9
4 Overview .................................................................................................................................................. 9
4.1 Introduction........................................................................................................................................................ 9
5 Services offered by the AUSF ................................................................................................................ 10
5.1 Introduction...................................................................................................................................................... 10
5.2 Nausf_UEAuthentication Service .................................................................................................................... 10
5.2.1 Service Description .................................................................................................................................... 10
5.2.2 Service Operations ..................................................................................................................................... 11
5.2.2.1 Introduction .......................................................................................................................................... 11
5.2.2.2 Authenticate .......................................................................................................................................... 11
5.2.2.2.1 General ............................................................................................................................................ 11
5.2.2.2.2 5G AKA .......................................................................................................................................... 11
5.2.2.2.3 EAP-based authentication method .................................................................................................. 12
5.2.2.2.3.1 General ...................................................................................................................................... 12
5.2.2.2.3.2 EAP method: EAP-AKA' .......................................................................................................... 12
5.2.2.2.3.3 EAP method: EAP-TLS ............................................................................................................ 14
5.3 Nausf_SoRProtection Service.......................................................................................................................... 14
5.3.1 Service Description .................................................................................................................................... 14
5.3.2 Service Operations ..................................................................................................................................... 14
5.3.2.1 Introduction .......................................................................................................................................... 14
5.3.2.2 Protect ................................................................................................................................................... 14
5.3.2.2.1 General ............................................................................................................................................ 14
5.4 Nausf_UPUProtection Service......................................................................................................................... 15
5.4.1 Service Description .................................................................................................................................... 15
5.4.2 Service Operations ..................................................................................................................................... 15
5.4.2.1 Introduction .......................................................................................................................................... 15
5.4.2.2 Protect ................................................................................................................................................... 15
5.4.2.2.1 General ............................................................................................................................................ 15
6 API Definitions ...................................................................................................................................... 16
6.1 Nausf_UEAuthentication Service API............................................................................................................. 16
6.1.1 API URI ..................................................................................................................................................... 16
6.1.2 Usage of HTTP .......................................................................................................................................... 16
6.1.2.1 General ................................................................................................................................................. 16
6.1.2.2 HTTP standard headers ........................................................................................................................ 16
6.1.2.2.1 General ............................................................................................................................................ 16
6.1.2.2.2 Content type .................................................................................................................................... 16
6.1.2.3 HTTP custom headers .......................................................................................................................... 17
6.1.2.3.1 General ............................................................................................................................................ 17
6.1.3 Resources ................................................................................................................................................... 17
6.1.3.1 Overview .............................................................................................................................................. 17
6.1.3.2 Resource: List of ue-authentications .................................................................................................... 18
6.1.3.2.1 Description ...................................................................................................................................... 18
6.1.3.2.2 Resource Definition ........................................................................................................................ 18
6.1.3.2.3 Resource Standard Methods............................................................................................................ 18
6.1.3.2.3.1 POST ......................................................................................................................................... 18
6.1.3.2.4 Resource Custom Operations .......................................................................................................... 19
6.1.3.2.4.1 Overview ................................................................................................................................... 19
6.1.3.3 Resource: 5g-aka-confirmation (Document) ........................................................................................ 19
3GPP
Release 16 4 3GPP TS 29.509 V16.0.0 (2019-06)
3GPP
Release 16 5 3GPP TS 29.509 V16.0.0 (2019-06)
3GPP
Release 16 6 3GPP TS 29.509 V16.0.0 (2019-06)
3GPP
Release 16 7 3GPP TS 29.509 V16.0.0 (2019-06)
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:
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.
3GPP
Release 16 8 3GPP TS 29.509 V16.0.0 (2019-06)
1 Scope
The present document specifies the stage 3 protocol and data model for the Nausf Service Based Interface. It provides
stage 3 protocol definitions and message flows, and specifies the API for each service offered by the AUSF.
The 5G System stage 2 architecture and procedures are specified in 3GPP TS 23.501 [2], 3GPP TS 23.502 [3] and
3GPP TS 33.501 [8].
The Technical Realization of the Service Based Architecture and the Principles and Guidelines for Services Definition
are specified in 3GPP TS 29.500 [4] and 3GPP TS 29.501 [5].
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 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.
[2] 3GPP TS 23.501: "System Architecture for the 5G System; Stage 2".
[4] 3GPP TS 29.500: "5G System; Technical Realization of Service Based Architecture; Stage 3".
[5] 3GPP TS 29.501: "5G System; Principles and Guidelines for Services Definition; Stage 3".
[7] IETF RFC 8259: "The JavaScript Object Notation (JSON) Data Interchange Format".
[9] IETF RFC 5448: "Improved Extensible Authentication Protocol Method for 3 rd Generation
Authentication and Key Agreement (EAP-AKA')".
Editor's Note: This reference may be removed and references to it updated when the IETF publishes the
corresponding update version.
[10] 3GPP TS 29.571: "5G System; Common Data Types for Service Based Interfaces; Stage 3".
[12] 3GPP TS 29.503: "5G System; Unified Data Management Services; Stage 3".
[15] 3GPP TS 31.102: "Characteristics of the Universal Subscriber Identity Module (USIM)
application".
3GPP
Release 16 9 3GPP TS 29.509 V16.0.0 (2019-06)
[17] Internet draft draft-ietf-emu-rfc5448bis: "Improved Extensible Authentication Protocol Method for
3rd Generation Authentication and Key Agreement (EAP-AKA')".
[19] IETF RFC 4648: "The Base16, Base32 and Base64 Data Encodings".
[20] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
3.1 Definitions
For the purposes of the present document, the terms and definitions given in 3GPP 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].
3.2 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].
4 Overview
4.1 Introduction
The Network Function (NF) Authentication Server Function (AUSF) is the network entity in the 5G Core Network
(5GC) supporting the following functionalities:
3GPP
Release 16 10 3GPP TS 29.509 V16.0.0 (2019-06)
AUSF
Nausf
AMF/ AMF/
UDM
SEAF SEAF
HPLMN VPLMN
This figure represents the AUSF architecture in the Service-based Architecture model. In the reference point model, the
interface between the AMF and the AUSF is named N12. In this release, the SEAF function is collocated with the
AMF. The AUSF may provide the service to the UDM.
5.1 Introduction
The AUSF offers to NF Service Consumers (e.g. AMF) the following services:
- Nausf_UEAuthentication
- Nausf_SoRProtection
- Nausf_UPUProtection
- Authenticate
This service permits to authenticate the UE and to provide one or more master keys which are used by the AMF to
derived subsequent keys.
3GPP
Release 16 11 3GPP TS 29.509 V16.0.0 (2019-06)
5.2.2.1 Introduction
The service operation defined for the Nausf_UEAuthentication is as follows:
5.2.2.2 Authenticate
5.2.2.2.1 General
The service operation "Authenticate" permits the requester NF to initiate the Authentication of the UE by providing the
following information to the AUSF:
- UE id (e.g. SUPI)
The AUSF retrieves the UE's subscribed authentication method from the UDM and depending on the information
provided by the UDM, the AUSF enters in one of the following procedures:
- 5G-AKA
- EAP-based authentication'
For those two different procedures a new resource is generated by the AUSF. The content of the resource will depend
on the procedure and will be returned to the AMF.
5.2.2.2.2 5G AKA
In this procedure, the NF Service Consumer (AMF) requests the authentication of the UE by providing UE related
information and the serving network name and the 5G AKA is selected. The NF Service Consumer (AMF) shall then
return to the AUSF the result received from the UE:
NF Service
AUSF
Consumer
3. PUT …/ue-authentications/{AuthCtxId}/5g-aka-confirmation(ConfirmationData)
4a. 200 OK
4b. 4xx/5xx (ProblemDetails)
1. The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall
contain at least the UE Id and the Serving Network Name.
2a. On success, "201 Created" shall be returned. The payload body shall contain the representation of the resource
created and the "Location" header shall contain the URI of the created resource (e.g.
3GPP
Release 16 12 3GPP TS 29.509 V16.0.0 (2019-06)
2b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1. If the serving network is not authorized, the AUSF shall use the
SERVING_NETWORK_NOT_AUTHORIZED "cause".
3. Based on the relation type, the NF Service Consumer (AMF) deduces that it shall send a PUT containing the
"RES*" provided by the UE to the URI provided by the AUSF or derived by itself. The NF Service Consumer
(AMF) shall also send a PUT containing null value in the RES* to indicate the failure to the AUSF for the
following cases:
- if the UE is not reached, and the RES* is never received by the NF Service Consumer (AMF);
- the comparation of the HRES* and HXRES* is unsuccessful in the NF Service Consumer (AMF);
- the authentication failure is received from the UE, e.g. synchronization failure or MAC failure;
4a. On success, "200 OK" shall be returned. If the UE is not authenticated, e.g. the verification of the RES* was not
successful in the AUSF, the AUSF shall set the value of AuthResult to AUTHENTICATION_FAILURE.
4b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
5.2.2.2.3.1 General
In this procedure, the NF Service Consumer requests the authentication of the UE by providing UE related information
and the serving network and the EAP-based authentication is selected (see IETF RFC 3748 [18]). EAP messages are
exchanged between a UE acting as EAP peer, an NF Service Consumer (AMF/SEAF) acting as a pass-through
authenticator and the AUSF acting as the EAP server.
3GPP
Release 16 13 3GPP TS 29.509 V16.0.0 (2019-06)
NF Service
AUSF
Consumer
1. The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall
contain at least the UE Id, Serving Network Name.
2a. On success, "201 Created" shall be returned. The payload body shall contain the representation of the resource
generated and the "Location" header shall contain the URI of the generated resource (e.g.
.../v1/ue_authentications/{authCtxId}/eap-session). The AUSF generates a sub-resource "eap-session". The
AUSF shall provide an hypermedia link towards this sub-resource in the payload to indicate to the AMF where it
shall send a POST containing the EAP packet response. The body payload shall also contain the EAP packet
EAP-Request/AKA'-Challenge.
2b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1. In particular, if the serving network is not authorized, the AUSF shall use the "Cause"
SERVING_NETWORK_NOT_AUTHORIZED.
3. Based on the relation type, the NF Service Consumer (AMF) shall send a POST request including the EAP-
Response/AKA' Challenge received from the UE. The POST request is sent to the URI provided by the AUSF or
derived by the NF Service Consumer (AMF).
4a. On success, and if the AUSF and the UE have indicated the use of protected successful result indications as in
IETF RFC 5448 [9] (to be superseded by draft-ietf-emu-rfc5448bis [17]), the AUSF shall reply with a "200 OK"
HTTP message containing the EAP Request/AKA' Notification and an hypermedia link towards the sub-resource
"eap-session".
4b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
5. The NF Service Consumer (AMF) shall send a POST request including the EAP Response/AKA' Notification
received from the UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service
Consumser (AMF).
3GPP
Release 16 14 3GPP TS 29.509 V16.0.0 (2019-06)
6a. If the EAP authentication exchange is successfully completed (with or without the optional Notification
Request/Response messages exchange), "200 OK" shall be returned to the NF Service Consumer (AMF). The
payload shall contain the result of the authentication, an EAP success/failure and the Kseaf if the authentication
is successful. If the UE is not authenticated, the AUSF shall set the authResult to
AUTHENTICATION_FAILURE.
6b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
The EAP-TLS method can be used in private networks as an EAP method (see 3GPP TS 33.501 [8] Annex B.1). The
corresponding stage 3 implementation is described in Annex B.
This service permits to provide the NF Service Consumer (e.g. UDM) with the SoR-MAC-IAUSF and CounterSoR to
protect the the Steering Information List from being tampered with or removed by the VPLMN.
NOTE: If the Steering Information List is not available or HPLMN determines that no steering of the UE is
required, a SOR transparent container information element with an HPLMN indication that 'no change of
the "Operator Controlled PLMN Selector with Access Technology" list stored in the UE' protected by
SoR-MAC-IAUSF and CounterSoR is still sent to the UE during registration. The Steering Information
List In such a case, the NF Service Consumer shall send an empty list to the AUSF when consuming the
Nausf_SoRProtection Service.
In option this service also allows to provide the NF Service Consumer (e.g. UDM) with the SoR-XMAC-IUE that
allows the NF Service Consumer (e.g. UDM) to verify that the UE received the Steering Information List.
5.3.2.1 Introduction
The service operation defined for the Nausf_SoRProtection is as follows:
- Protect
5.3.2.2 Protect
5.3.2.2.1 General
The Protect service operation is used in the following procedures:
- Procedure for steering of UE in VPLMN during registration (see clause 6.14.2.1 of 3GPP TS 33.501 [8]);
- Procedure for steering of UE in VPLMN after registration (see clause 6.14.2.2 of 3GPP TS 33.501 [8]).
The NF Service Consumer (e.g. UDM) uses this service operation to request the AUSF to compute the SoR-MAC-
IAUSF and the CounterSoR by providing Steering Information List. The NF Service Consumer (e.g. UDM) may also
request the AUSF to compute the SoR-XMAC-IUE by providing the indication that an acknowledgement is requested
from the UE.
3GPP
Release 16 15 3GPP TS 29.509 V16.0.0 (2019-06)
NF Service
AUSF
Consumer
1. The NF Service Consumer (e.g. UDM) shall send a POST request to the AUSF that was used to authenticate the
UE. The payload of the body shall contain the Steering Information List and the acknowledge indication.
2a. On success, "200 OK" shall be returned. The payload body shall contain the requested security material
necessary to protect the Steering of Roaming procedure.
2b. On failure, one of the HTTP status code listed in table 6.2.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.2.7.3-1. If the CounterSoR associated with the KAUSF of the UE, is about to wrap around, the AUSF shall use the
"COUNTER-WRAP" cause.
This service permits to provide the NF Service Consumer (e.g. UDM) with the UPU-MAC-IAUSF and CounterUPU to
protect the UE Parameters Update Data from being tampered with or removed by the VPLMN.
In option this service also allows to provide the NF Service Consumer (e.g. UDM) with the UPU-XMAC-IUE that
allows the NF Service Consumer (e.g. UDM) to verify that the UE received UE Parameters Update Data correctly.
5.4.2.1 Introduction
The service operation defined for the Nausf_UPUProtection is as follows:
- Protect
5.4.2.2 Protect
5.4.2.2.1 General
The Protect service operation is used in the following procedures:
- Procedure for UE Parameters Update (see clause 6.15.2.1 of 3GPP TS 33.501 [8]).
The NF Service Consumer (e.g. UDM) uses this service operation to request the AUSF to compute the UPU-MAC-
IAUSF and CounterUPU by providing the UE Parameters Update Data (UPU Data). The NF Service Consumer (e.g. UDM)
may also request the AUSF to compute the UPU-XMAC-IUE by providing the indication that an acknowledgement is
requested from the UE.
3GPP
Release 16 16 3GPP TS 29.509 V16.0.0 (2019-06)
NF Service
AUSF
Consumer
1. The NF Service Consumer (e.g. UDM) shall send a POST request to the AUSF that was used to authenticate the
UE. The payload of the body shall contain the UE Parameters Update Data (UPU Data) and the acknowledge
indication.
2a. On success, "200 OK" shall be returned. The payload body shall contain the requested security material
necessary to protect the UE Parameters Update procedure.
2b. On failure, one of the HTTP status code listed in table 6.4.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.4.7.3-1. If the CounterUPU associated with the KAUSF of the UE, is about to wrap around, the AUSF shall use the
"COUNTER-WRAP" cause.
6 API Definitions
{apiRoot}/{apiName}/{apiVersion}/
where "apiRoot" is defined in clause 4.4.1 of 3GPP TS 29.501 [5], the "apiName" shall be set to "nausf-auth" and the
"apiVersion" shall be set to "v1" for the current version of this specification.
6.1.2.1 General
HTTP/2, as defined in IETF RFC 7540 [6], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].
6.1.2.2.1 General
The usage of HTTP standard headers is specified in clause 5.2.2 of 3GPP TS 29.500 [4].
3GPP
Release 16 17 3GPP TS 29.509 V16.0.0 (2019-06)
- JSON, as defined in IETF RFC 8259 [7], shall be used as content type of the HTTP bodies specified in the
present specification as indicated in clause 5.4 of 3GPP TS 29.500 [4].
- The Problem Details JSON Object (IETF RFC 7807 [11]. The use of the Problem Details JSON object in a
HTTP response body shall be signalled by the content type "application/problem+json"
- The 3GPP hypermedia format as defined in 3GPP TS 29.501 [5]. The use of the 3GPP hypermedia format in a
HTTP response body shall be signalled by the content type "application/3gppHal+json"
6.1.2.3.1 General
The usage of HTTP custom headers shall be supported as specified in clause 5.2.3 of 3GPP TS 29.500 [4].
6.1.3 Resources
6.1.3.1 Overview
The structure of the Resource URIs of the "Authenticate" service is shown in Figure 6.1.3.1-1
//{apiRoot}/nausf-ausf/v1
/ue-authentications
/{authCtxId}
/5g-aka-confirmation
/eap-session
Table 6.1.3.1-1 provides an overview of the resources and applicable HTTP methods.
3GPP
Release 16 18 3GPP TS 29.509 V16.0.0 (2019-06)
HTTP
method
Resource name Resource URI or Description
custom
operation
ue-authentications {apiRoot}/nausf-auth/v1/ue-authentications POST Initiate the authentication
(Collection) process by providing inputs
related to the UE
5g-aka-confirmation {apiRoot}/nausf-auth/v1/ue- PUT Put the UE response from
(Document) authentications/{authCtxId}/5g-aka-confirmation the 5G-AKA process.
6.1.3.2.1 Description
This resource represents a collection of the ue-authentication resources generated by the AUSF.
This resource shall support the resource URI variables defined in table 6.1.3.2.2-1.
Name Definition
apiRoot See clause 6.1.1
6.1.3.2.3.1 POST
This method shall support the URI query parameters specified in table 6.1.3.2.3.1-1.
Table 6.1.3.2.3.1-1: URI query parameters supported by the POST method on this resource
This method shall support the request data structures specified in table 6.1.3.2.3.1-2 and the response data structures and
response codes specified in table 6.1.3.2.3.1-3.
Table 6.1.3.2.3.1-2: Data structures supported by the POST Request Body on this resource
3GPP
Release 16 19 3GPP TS 29.509 V16.0.0 (2019-06)
Table 6.1.3.2.3.1-3: Data structures supported by the POST Response Body on this resource
6.1.3.2.4.1 Overview
6.1.3.3.1 Description
The subresource "5g-aka-confirmation" is generated by the AUSF. This subresource should not persist after the AUSF
has read its content.
This resource shall support the resource URI variables defined in table 6.1.3.2.2-1.
3GPP
Release 16 20 3GPP TS 29.509 V16.0.0 (2019-06)
Name Definition
apiRoot See clause 6.1.1
authCtxId Represents a specific ue-authentication
6.1.3.3.3.1 PUT
This method shall support the URI query parameters specified in table 6.1.3.2.3.1-1.
Table 6.1.3.2.3.1-1: URI query parameters supported by the PUT method on this resource
This method shall support the request data structures specified in table 6.1.3.2.3.1-2 and the response data structures and
response codes specified in table 6.1.3.2.3.1-3.
Table 6.1.3.3.3.1-2: Data structures supported by the PUT Request Body on this resource
Table 6.1.3.3.3.1-3: Data structures supported by the PUT Response Body on this resource
6.1.3.4.1 Description
The "eap-session" is generated by the AUSF if an EAP-based authentication method is selected. This resource is used to
handle the EAP session. This subresource should not persist after the EAP exchanges.
This resource shall support the resource URI variables defined in table 6.1.3.4.2-1.
3GPP
Release 16 21 3GPP TS 29.509 V16.0.0 (2019-06)
Name Definition
apiRoot See clause 6.1.1
authCtxId Represents a specifc ue-authentication
6.1.3.4.3.1 POST
This method shall support the URI query parameters specified in table 6.1.3.4.3.1-1.
Table 6.1.3.4.3.1-1: URI query parameters supported by the POST method on this resource
This method shall support the request data structures specified in table 6.1.3.4.3.1-2 and the response data structures and
response codes specified in table 6.1.3.4.3.1-3.
Table 6.1.3.4.3.1-2: Data structures supported by the POST Request Body on this resource
Table 6.1.3.4.3.1-3: Data structures supported by the POST Response Body on this resource
6.1.4.1 Overview
There is no Custom Operation in the current version of this API.
6.1.5 Notifications
6.1.5.1 General
There is no use of notification in the current version of this API.
3GPP
Release 16 22 3GPP TS 29.509 V16.0.0 (2019-06)
6.1.6.1 General
This clause specifies the application data model supported by the API.
Table 6.1.6.1-1 specifies the data types defined for the Nausf service based interface protocol.
Table 6.1.6.1-2 specifies data types re-used by the Nausf service based interface protocol from other specifications,
including a reference to their respective specifications and when needed, a short description of their use within the
Nausf service based interface.
6.1.6.2.1 Introduction
The following clause defines the structures to be used in resource representations.
3GPP
Release 16 23 3GPP TS 29.509 V16.0.0 (2019-06)
3GPP
Release 16 24 3GPP TS 29.509 V16.0.0 (2019-06)
6.1.6.3.1 Introduction
This clause defines simple data types and enumerations that can be referenced from data structures defined in the
previous clauses.
3GPP
Release 16 25 3GPP TS 29.509 V16.0.0 (2019-06)
6.1.6.3.5.1 General
This clause describes the possible relation types defined within AUSF API.
Relation Name
5g-aka
eap-session
The value "5g-aka" specifies that the value of the href attribute is the URI where NF Service Consumer shall send a
PUT containing the result "RES*" received from the UE.
The value "eap-session" specifies that the value of the href attribute is the URI that will be used by the NF Service
Consumer to provide EAP packet response during an EAP exchange. The NF Service Consumer shall use a POST to
provide the EAP Packet Response to the AUSF to the corresponding URI.
6.1.6.4.1 Introduction
There is no binary data in the current version of this API.
6.1.7.1 General
HTTP error handling shall be supported as specified in clause 5.2.4 of 3GPP TS 29.500 [4].
3GPP
Release 16 26 3GPP TS 29.509 V16.0.0 (2019-06)
6.1.8 Security
As indicated in 3GPP TS 33.501 [8], the access to the Nausf_UEAuthentication Service API may be authorized by
means of the Oauth2 protocol (see IETF RFC 6749 [13]), using the "Client Credentials" authorization grant, where the
NRF (see 3GPP TS 29.510 [14]) plays the role of the authorization server.
If OAuth2 is used, an NF Service Consumer, prior to consuming service offered by the Nausf_UEAuthentication
Service API, shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as
described in 3GPP TS 29.510 [14], clause 5.4.2.2.
NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF
that the NF Service Consumer used for discovering the Nausf_UEAuthentication service.
The Nausf_UEAuthentication Service API does not define any scopes for Oauth2 authorization as specified in
3GPP TS 33.501 [8]; it defines a single scope consisting on the name of the service (i.e., "nausf-auth"), and it does not
define any additional scopes at resource or operation level.
3GPP
Release 16 27 3GPP TS 29.509 V16.0.0 (2019-06)
{apiRoot}/{apiName}/{apiVersion}/
where "apiRoot" is defined in clause 4.4.1 of 3GPP TS 29.501 [5], the "apiName" shall be set to "nausf-sorprotection"
and the "apiVersion" shall be set to "v1" for the current version of this specification.
6.2.2.1 General
HTTP/2, as defined in IETF RFC 7540 [6], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].
6.2.2.2.1 General
The usage of HTTP standard headers is specified in clause 5.2.2 of 3GPP TS 29.500 [4].
- JSON, as defined in IETF RFC 8259 [7], shall be used as content type of the HTTP bodies specified in the
present specification as indicated in clause 5.4 of 3GPP TS 29.500 [4].
- The Problem Details JSON Object (IETF RFC 7807 [11]. The use of the Problem Details JSON object in a
HTTP response body shall be signalled by the content type "application/problem+json"
6.2.2.3.1 General
In this version of the API, no specific custom headers are defined for the "Nausf_SoRProtection" service.
For 3GPP specific HTTP custom headers used across all service based interfaces, see clause 5.2.3 of
3GPP TS 29.500 [4].
6.2.3 Resources
6.2.3.1 Overview
The structure of the Resource URIs of the SoRProtection service is shown in Figure 6.2.3.1-1
3GPP
Release 16 28 3GPP TS 29.509 V16.0.0 (2019-06)
//{apiRoot}/nausf-sorprotection/v1
/{supi}
/ue-sor
Table 6.2.3.1-1 provides an overview of the resources and applicable HTTP methods.
HTTP
method
Resource name Resource URI or Description
custom
operation
ue-sor {apiRoot}/nausf-sorprotection/v1/{supi}/ue- generate- Resource for SoR security
(Custom operation) sor/generate-sor-data sor-data material computation
(POST)
6.2.3.2.1 Description
It is the resource to which the custom operation used to generate the SoR security material is associated with.
This resource shall support the resource URI variables defined in table 6.2.3.2.2-1.
Name Definition
apiRoot See clause 6.2.1
supi Represents the Subscription Permanent Identifier (see 3GPP TS 23.501 [2] clause 5.9.2)
pattern: '^(imsi-[0-9]{5,15}|nai-.+|.+)$'
3GPP
Release 16 29 3GPP TS 29.509 V16.0.0 (2019-06)
6.2.3.2.4.1 Overview
Mapped HTTP
Custom operation URI Description
method
/generate-sor-data POST The AUSF calculates the SoR-MAC-IAUSF and
the CounterSoR to protect the Steering
Information List provided. It may also calculate
the SoR-XMAC-IUE to verify that the UE
received the Steering Information List if the
indication that an acknowledgement is
requested from the UE.
6.2.3.2.4.2.1 Description
This custom operation is used by the NF service consumer (e.g. UDM) to request the AUSF to compute the security
material (SoR-MAC-IAUSF, CounterSoR and SoR-XMAC-IUE) needed to ensure the protection of the SoR procedure
(see 3GPP TS 33.501 [8]).
This method shall support the request data structures specified in table 6.2.3.2.4.2.2-1 and the response data structures
and response codes specified in table 6.2.3.2.4.2.2-2.
Table 6.2.3.2.4.2.2-1: Data structures supported by the POST Request Body on this resource
Table 6.2.3.2.4.2.2-2: Data structures supported by the POST Response Body on this resource
6.2.4.1 Overview
There is no Custom Operation in the current version of this API.
3GPP
Release 16 30 3GPP TS 29.509 V16.0.0 (2019-06)
6.2.5 Notifications
6.2.5.1 General
There is no use of notification in the current version of this API.
6.2.6.1 General
This clause specifies the application data model supported by the API.
Table 6.2.6.1-1 specifies the data types defined for the Nausf-SORProtection service based interface protocol.
Table 6.2.6.1-2 specifies data types re-used by the Nausf-SORProtection service based interface protocol from other
specifications, including a reference to their respective specifications and when needed, a short description of their use
within the Nausf service based interface.
6.2.6.2.1 Introduction
The following clauses define the structures to be used in resource representations.
3GPP
Release 16 31 3GPP TS 29.509 V16.0.0 (2019-06)
3GPP
Release 16 32 3GPP TS 29.509 V16.0.0 (2019-06)
6.2.6.3.1 Introduction
This clause defines simple data types and enumerations that can be referenced from data structures defined in the
previous clauses.
6.2.7.1 General
HTTP error handling shall be supported as specified in clause 5.2.4 of 3GPP TS 29.500 [4].
3GPP
Release 16 33 3GPP TS 29.509 V16.0.0 (2019-06)
6.2.8 Security
As indicated in 3GPP TS 33.501 [8], the access to the Nausf_SoRProtection API may be authorized by means of the
OAuth2 protocol (see IETF RFC 6749 [13]), using the "Client Credentials" authorization grant, where the NRF (see
3GPP TS 29.510 [14]) plays the role of the authorization server.
If OAuth2 is used, an NF Service Consumer, prior to consuming services offered by the Nausf_SoRProtection API,
shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in
3GPP TS 29.510 [14], clause 5.4.2.2.
NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF
that the NF Service Consumer used for discovering the Nausf_SoRProtection service.
The Nausf_SoRProtection Service API does not define any scopes for OAuth2 authorization as specified in
3GPP TS 33.501 [8]; it defines a single scope consisting on the name of the service (i.e., "nausf-sorprotection"), and it
does not define any additional scopes at resource or operation level.
{apiRoot}/{apiName}/{apiVersion}/
where "apiRoot" is defined in clause 4.4.1 of 3GPP TS 29.501 [5], the "apiName" shall be set to "nausf-upuprotection"
and the "apiVersion" shall be set to "v1" for the current version of this specification.
6.3.2.1 General
HTTP/2, as defined in IETF RFC 7540 [6], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].
6.3.2.2.1 General
The usage of HTTP standard headers is specified in clause 5.2.2 of 3GPP TS 29.500 [4].
- JSON, as defined in IETF RFC 8259 [7], shall be used as content type of the HTTP bodies specified in the
present specification as indicated in clause 5.4 of 3GPP TS 29.500 [4].
3GPP
Release 16 34 3GPP TS 29.509 V16.0.0 (2019-06)
- The Problem Details JSON Object (IETF RFC 7807 [11]. The use of the Problem Details JSON object in a
HTTP response body shall be signalled by the content type "application/problem+json"
6.3.2.3.1 General
In this version of the API, no specific custom headers are defined for the "Nausf_UPUProtection" service.
For 3GPP specific HTTP custom headers used across all service based interfaces, see clause 5.2.3 of
3GPP TS 29.500 [4].
6.3.3 Resources
6.3.3.1 Overview
The structure of the Resource URIs of the UPUProtection service is shown in Figure 6.3.3.1-1
//{apiRoot}/nausf-upuprotection/v1
/{supi}
/ue-upu
Table 6.3.3.1-1 provides an overview of the resources and applicable HTTP methods.
HTTP
method
Resource name Resource URI or Description
custom
operation
ue-upu {apiRoot}/nausf-upuprotection/v1/{supi}/ue- generate- Resource for UPU security
(Custom operation) upu/generate-upu-data upu-data material computation
(POST)
6.3.3.2.1 Description
It is the resource to which the custom operation used to generate the UPU security material is associated with.
This resource shall support the resource URI variables defined in table 6.3.3.2.2-1.
3GPP
Release 16 35 3GPP TS 29.509 V16.0.0 (2019-06)
Name Definition
apiRoot See clause 6.3.1
supi Represents the Subscription Permanent Identifier (see 3GPP TS 23.501 [2] clause 5.9.2)
pattern: '^(imsi-[0-9]{5,15}|nai-.+|.+)$'
6.3.3.2.4.1 Overview
Mapped HTTP
Custom operation URI Description
method
/generate-upu-data POST The AUSF calculates the UPU-MAC-IAUSF and
the CounterUPU to protect the UE Parameters
Update Data provided. It may also calculate the
UPU-XMAC-IUE to verify that the UE received
the UE Parameters Update Data if the
indication that an acknowledgement is
requested from the UE is provided.
6.3.3.2.4.2.1 Description
This custom operation is used by the NF service consumer (e.g. UDM) to request the AUSF to compute the security
material (UPU-MAC-IAUSF, CounterUPU and UPU-XMAC-IUE) needed to ensure the protection of the UPU procedure
(see 3GPP TS 33.501 [8]).
This method shall support the request data structures specified in table 6.3.3.2.4.2.2-1 and the response data structures
and response codes specified in table 6.3.3.2.4.2.2-2.
Table 6.3.3.2.4.2.2-1: Data structures supported by the POST Request Body on this resource
Table 6.3.3.2.4.2.2-2: Data structures supported by the POST Response Body on this resource
3GPP
Release 16 36 3GPP TS 29.509 V16.0.0 (2019-06)
6.3.4.1 Overview
There is no Custom Operation in the current version of this API.
6.3.5 Notifications
6.3.5.1 General
There is no use of notification in the current version of this API.
6.3.6.1 General
This clause specifies the application data model supported by the API.
Table 6.3.6.1-1 specifies the data types defined for the Nausf-UPUProtection service based interface protocol.
Table 6.3.6.1-2 specifies data types re-used by the Nausf-UPUProtection service based interface protocol from other
specifications, including a reference to their respective specifications and when needed, a short description of their use
within the Nausf service based interface.
6.3.6.2.1 Introduction
The following clauses define the structures to be used in resource representations.
3GPP
Release 16 37 3GPP TS 29.509 V16.0.0 (2019-06)
6.3.6.3.1 Introduction
This clause defines simple data types and enumerations that can be referenced from data structures defined in the
previous clauses.
3GPP
Release 16 38 3GPP TS 29.509 V16.0.0 (2019-06)
6.3.7.1 General
HTTP error handling shall be supported as specified in clause 5.2.4 of 3GPP TS 29.500 [4].
6.3.8 Security
As indicated in 3GPP TS 33.501 [8], the access to the Nausf_UPUProtection API may be authorized by means of the
OAuth2 protocol (see IETF RFC 6749 [13]), using the "Client Credentials" authorization grant, where the NRF (see
3GPP TS 29.510 [14]) plays the role of the authorization server.
If OAuth2 is used, an NF Service Consumer, prior to consuming services offered by the Nausf_UPUProtection API,
shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in
3GPP TS 29.510 [14], clause 5.4.2.2.
NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF
that the NF Service Consumer used for discovering the Nausf_UPUProtection service.
The Nausf_UPUProtection Service API does not define any scopes for OAuth2 authorization as specified in
3GPP TS 33.501 [8]; it defines a single scope consisting on the name of the service (i.e., "nausf-upuprotection"), and it
does not define any additional scopes at resource or operation level.
3GPP
Release 16 39 3GPP TS 29.509 V16.0.0 (2019-06)
Annex A (normative):
OpenAPI specification
A.1 General
This Annex specifies the formal definition of the Nausf Service API(s). It consists of OpenAPI 3.0.0 specifications in
YAML format.
NOTE 1: OpenAPI 3.0 does not support description of API using HATEOAS. Indeed, only relative paths can be
used and as a consequence the URI provided in the "href" cannot be reused as it is.
This Annex takes precedence when being discrepant to other parts of the specification with respect to the encoding of
information elements and methods within the API(s).
NOTE 2: The semantics and procedures, as well as conditions, e.g. for the applicability and allowed combinations
of attributes or values, not expressed in the OpenAPI definitions but defined in other parts of the
specification also apply.
Informative copies of the OpenAPI specification files contained in this 3GPP Technical Specification are available on
the public 3GPP file server in the following locations (see clause 5B of the 3GPP TR 21.900 [21] for further
information):
- https://www.3gpp.org/ftp/Specs/archive/OpenAPI/<Release>/, and
- https://www.3gpp.org/ftp/Specs/<Plenary>/<Release>/OpenAPI/.
NOTE 3: To fetch the OpenAPI specification file after CT#83 plenary meeting for Release 15 in the above links
<Plenary> must be replaced with the date the CT Plenary occurs, in the form of year-month (yyyy-mm),
e.g. for CT#83 meeting <Plenary> must be replaced with value "2019-03" and <Release> must be
replaced with value "Rel-15".
servers:
- url: '{apiRoot}/nausf-auth/v1'
variables:
apiRoot:
default: https://example.com
description: apiRoot as defined in clause clause 4.4 of 3GPP TS 29.501.
security:
- {}
- oAuth2ClientCredentials:
- nausf-auth
paths:
/ue-authentications:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/AuthenticationInfo'
3GPP
Release 16 40 3GPP TS 29.509 V16.0.0 (2019-06)
required: true
responses:
'201':
description: UEAuthenticationCtx
content:
application/3gppHal+json:
schema:
$ref: '#/components/schemas/UEAuthenticationCtx'
headers:
Location:
description: 'Contains the URI of the newly created resource according to the
structure: {apiRoot}/nausf-auth/v1/ue-authentications/{authCtxId}'
required: true
schema:
type: string
'400':
description: Bad Request from the AMF
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
'403':
description: Forbidden due to serving network not authorized
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
'500':
description: Internal Server Error
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
/ue-authentications/{authCtxId}/5g-aka-confirmation:
put:
parameters:
- name: authCtxId
in: path
required: true
schema:
type: string
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/ConfirmationData'
responses:
'200':
description: Request processed (EAP success or Failure)
content:
application/json:
schema:
$ref: '#/components/schemas/ConfirmationDataResponse'
'400':
description: Bad Request
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
'500':
description: Internal Server Error
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
/ue-authentications/{authCtxId}/eap-session:
post:
operationId: EapAuthMethod
parameters:
- name: authCtxId
in: path
required: true
schema:
type: string
requestBody:
content:
3GPP
Release 16 41 3GPP TS 29.509 V16.0.0 (2019-06)
application/json:
schema:
$ref: '#/components/schemas/EapSession'
responses:
'200':
description: Use to handle or close the EAP session
content:
application/json:
schema:
$ref: '#/components/schemas/EapSession'
application/3gppHal+json:
schema:
type: object
properties:
eapPayload:
$ref: '#/components/schemas/EapPayload'
_links:
type: object
description: 'URI : /{eapSessionUri}'
additionalProperties:
$ref: 'TS29571_CommonData.yaml#/components/schemas/LinksValueSchema'
minProperties: 1
required:
- eapPayload
- _links
'400':
description: Bad Request
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
'500':
description: Internal Server Error
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
components:
securitySchemes:
oAuth2ClientCredentials:
type: oauth2
flows:
clientCredentials:
tokenUrl: '{nrfApiRoot}/oauth2/token'
scopes:
nausf-auth: Access to Nausf_UEAuthentication API
schemas:
AuthenticationInfo:
type: object
properties:
supiOrSuci:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/SupiOrSuci'
servingNetworkName:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/ServingNetworkName'
resynchronizationInfo:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/ResynchronizationInfo'
pei:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Pei'
traceData:
$ref: 'TS29571_CommonData.yaml#/components/schemas/TraceData'
udmGroupId:
$ref: 'TS29571_CommonData.yaml#/components/schemas/NfGroupId'
routingIndicator:
type: string
pattern: '^[0-9]{1,4}$'
required:
- supiOrSuci
- servingNetworkName
UEAuthenticationCtx:
type: object
properties:
authType:
$ref: '#/components/schemas/AuthType'
5gAuthData:
oneOf:
- $ref: '#/components/schemas/Av5gAka'
- $ref: '#/components/schemas/EapPayload'
3GPP
Release 16 42 3GPP TS 29.509 V16.0.0 (2019-06)
_links:
type: object
additionalProperties:
$ref: 'TS29571_CommonData.yaml#/components/schemas/LinksValueSchema'
servingNetworkName:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/ServingNetworkName'
required:
- authType
- 5gAuthData
- _links
Av5gAka:
type: object
required:
- rand
- hxresStar
- autn
properties:
rand:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/Rand'
hxresStar:
$ref: '#/components/schemas/HxresStar'
autn:
$ref: 'TS29503_Nudm_UEAU.yaml#/components/schemas/Autn'
ConfirmationData:
type: object
required:
- resStar
properties:
resStar:
$ref: '#/components/schemas/ResStar'
ConfirmationDataResponse:
type: object
properties:
authResult:
$ref: '#/components/schemas/AuthResult'
supi:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'
kseaf:
$ref: '#/components/schemas/Kseaf'
required:
- authResult
EapSession:
type: object
properties:
eapPayload:
$ref: '#/components/schemas/EapPayload'
kSeaf:
$ref: '#/components/schemas/Kseaf'
_links:
type: object
additionalProperties:
$ref: 'TS29571_CommonData.yaml#/components/schemas/LinksValueSchema'
authResult:
$ref: '#/components/schemas/AuthResult'
supi:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'
required:
- eapPayload
AuthResult:
type: string
enum:
- AUTHENTICATION_SUCCESS
- AUTHENTICATION_FAILURE
- AUTHENTICATION_ONGOING
EapPayload:
type: string
format: base64
description: contains an EAP packet
Kseaf:
type: string
pattern: '[A-Fa-f0-9]{64}'
ResStar:
type: string
pattern: '[A-Fa-f0-9]{32}'
nullable: true
3GPP
Release 16 43 3GPP TS 29.509 V16.0.0 (2019-06)
HxresStar:
type: string
pattern: "[A-Fa-f0-9]{32}"
AuthType:
anyOf:
- type: string
enum:
- 5G_AKA
- EAP_AKA_PRIME
- EAP_TLS
- type: string
externalDocs:
description: 3GPP TS 29.509 V16.0.0; 5G System; 3GPP TS Authentication Server services.
url: http://www.3gpp.org/ftp/Specs/archive/29_series/29.509
servers:
- url: '{apiRoot}/nausf-sorprotection/v1'
variables:
apiRoot:
default: https://example.com
description: apiRoot as defined in clause 4.4 of 3GPP TS 29.501
security:
- {}
- oAuth2ClientCredentials:
- nausf-sorprotection
paths:
/{supi}/ue-sor:
post:
parameters:
- name: supi
in: path
description: Identifier of the UE
required: true
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/SorInfo'
required: true
responses:
'200':
description: SorSecurityInfo
content:
application/json:
schema:
$ref: '#/components/schemas/SorSecurityInfo'
'503':
description: Service Unavailable
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
components:
securitySchemes:
oAuth2ClientCredentials:
type: oauth2
flows:
clientCredentials:
tokenUrl: '{nrfApiRoot}/oauth2/token'
scopes:
nausf-sorprotection: Access to the Nausf_SoRProtection API
schemas:
3GPP
Release 16 44 3GPP TS 29.509 V16.0.0 (2019-06)
SorInfo:
type: object
properties:
steeringContainer:
$ref: '#/components/schemas/SteeringContainer'
ackInd:
$ref: '#/components/schemas/AckInd'
required:
- ackInd
SorSecurityInfo:
type: object
properties:
sorMacIausf:
$ref: '#/components/schemas/SorMac'
counterSor:
$ref: '#/components/schemas/CounterSor'
sorXmacIue:
$ref: '#/components/schemas/SorMac'
required:
- sorMacIausf
- counterSor
SteeringContainer:
oneOf:
- type: array
items:
$ref: 'TS29509_Nausf_SoRProtection.yaml#/components/schemas/SteeringInfo'
minItems: 1
- $ref: '#/components/schemas/SecuredPacket'
SteeringInfo:
type: object
properties:
plmnId:
$ref: 'TS29571_CommonData.yaml#/components/schemas/PlmnId'
accessTechList:
type: array
items:
$ref: '#/components/schemas/AccessTech'
minItems: 1
required:
- plmnId
SorMac:
type: string
pattern: '^[A-Fa-f0-9]{32}$'
CounterSor:
type: string
pattern: '^[A-Fa-f0-9]{4}$'
AckInd:
type: boolean
SecuredPacket:
type: string
format: base64
AccessTech:
anyOf:
- type: string
enum:
- NR
- EUTRAN_IN_WBS1_MODE_AND_NBS1_MODE
- EUTRAN_IN_NBS1_MODE_ONLY
- EUTRAN_IN_WBS1_MODE_ONLY
- UTRAN
- GSM_AND_ECGSM_IoT
- GSM_WITHOUT_ECGSM_IoT
- ECGSM_IoT_ONLY
- CDMA_1xRTT
- CDMA_HRPD
- GSM_COMPACT
- type: string
externalDocs:
description: 3GPP TS 29.509 V15.3.0; 5G System; Authentication Server Services
url: 'http://www.3gpp.org/ftp/Specs/archive/29_series/29.509'
3GPP
Release 16 45 3GPP TS 29.509 V16.0.0 (2019-06)
info:
version: 1.0.1
title: Nausf_UPUProtection Service
description: |
AUSF UPU Protection Service
© 2019, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
Servers:
- url: '{apiRoot}/nausf-upuprotection/v1'
variables:
apiRoot:
default:
description: apiRoot as defined in clause 4.4 of 3GPP TS 29.501
security:
- {}
- oAuth2ClientCredentials:
- nausf-upuprotection
paths:
/{supi}/ue-upu:
post:
parameters:
- name: supi
in: path
description: Identifier of the UE
required: true
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Supi'
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/UpuInfo'
required: true
responses:
'200':
description: UpuSecurityInfo
content:
application/json:
schema:
$ref: '#/components/schemas/UpuSecurityInfo'
'503':
description: Service Unavailable
content:
application/problem+json:
schema:
$ref: 'TS29571_CommonData.yaml#/components/schemas/ProblemDetails'
components:
securitySchemes:
oAuth2ClientCredentials:
type: oauth2
flows:
clientCredentials:
tokenUrl: '{nrfApiRoot}/oauth2/token'
scopes:
nausf-upuprotection: Access to the Nausf_UPUProtection API
schemas:
UpuInfo:
type: object
properties:
upuDataList:
type: array
items:
$ref: '#/components/schemas/UpuData'
minItems: 1
upuAckInd:
$ref: '#/components/schemas/UpuAckInd'
required:
- upuDataList
- upuAckInd
UpuSecurityInfo:
type: object
properties:
upuMacIausf:
$ref: '#/components/schemas/UpuMac'
counterUpu:
$ref: '#/components/schemas/CounterUpu'
3GPP
Release 16 46 3GPP TS 29.509 V16.0.0 (2019-06)
upuXmacIue:
$ref: '#/components/schemas/UpuMac'
required:
- upuMacIausf
- counterUpu
UpuData:
type: object
properties:
secPacket:
$ref: 'TS29509_Nausf_SoRProtection.yaml#/components/schemas/SecuredPacket'
defaultConfNssai:
type: array
items:
$ref: 'TS29571_CommonData.yaml#/components/schemas/Snssai'
minItems: 1
oneOf:
- required: [secPacket]
- required: [defaultConfNssai]
UpuMac:
type: string
pattern: '^[A-Fa-f0-9]{32}$'
CounterUpu:
type: string
pattern: '^[A-Fa-f0-9]{4}$'
UpuAckInd:
type: boolean
externalDocs:
description: 3GPP TS 29.509 V15.3.0; 5G System; Authentication Server Services
url: 'http://www.3gpp.org/ftp/Specs/archive/29_series/29.509'
Annex B (Informative):
Use of EAP-TLS
B.1 General
The Annex B of 3GPP TS 33 501 [8] describes the use of EAP-TLS as an alternative authentication method in the case
of private network. This annex describes corresponding stage 3.
3GPP
Release 16 47 3GPP TS 29.509 V16.0.0 (2019-06)
NF Service
AUSF
Consumer
1 The NF Service Consumer (AMF) shall send a POST request to the AUSF. The payload of the body shall
contain at least the UE Id and Serving Network Name.
2a. On success, "201 Created" shall be returned. The payload body shall contain the representation of the resource
generated and the "Location" header shall contain the URI of the generated resource (e.g.
.../v1/ue_authentications/{authCtxId}/eap-session). The AUSF generates a sub-resource "eap-session". The
AUSF shall provide a hypermedia link towards this sub-resource in the payload to indicate to the AMF where it
shall send a POST containing the EAP packet response. The body payload shall also contain the EAP packet
EAP-Request/EAP-Type=EAP-TLS (TLS Start)
2b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1. In particular, if the serving network is not authorized, the AUSF shall use the "Cause"
SERVING_NETWORK_NOT_AUTHORIZED.
3. Based on the relation type, the NF Service Consumer (AMF) shall send a POST request including the EAP-
Response/EAP-Type=EAP-TLS (TLS client_hello) received from the UE. The POST request is sent to the URI
provided by the AUSF or derived by the NF Service Consumer (AMF).
4a. On success, the AUSF shall reply with a "200 OK" HTTP message containing the EAP Request as described in
Annex B.2.1 of 3GPP TS 33.501[a] and a hypermedia link towards the sub-resource "eap-session".
4b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
5. The NF Service Consumer (AMF) shall send a POST request including the EAP Response received from the
UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF).
3GPP
Release 16 48 3GPP TS 29.509 V16.0.0 (2019-06)
6a. On success, the AUSF shall reply with a "200 OK" HTTP message containing the EAP Request as described in
Annex B.2.1 of 3GPP TS 33.501[a] and a hypermedia link towards the sub-resource "eap-session".
6b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
7. The NF Service Consumer (AMF) shall send a POST request including the EAP Response received from the
UE. The POST request is sent to the URI provided by the AUSF or derived by the NF Service Consumer (AMF).
8a. If the EAP authentication exchange is successfully completed (with or without the optional Notification
Request/Response messages exchange), "200 OK" shall be returned to the NF Service Consumer (AMF). The
payload shall contain the result of the authentication, an EAP success/failure and the Kseaf if the authentication
is successful.
8b. On failure, one of the HTTP status code listed in table 6.1.7.3-1 shall be returned with the message body
containing a ProblemDetails structure with the "cause" attribute set to one of the application error listed in Table
6.1.7.3-1.
Annex C (informative):
Withdrawn API versions
C.1 General
This Annex lists withdrawn API versions of the APIs defined in the present specification. 3GPP TS 29.501 [5]
clause 4.3.1.6 describes the withdrawal of API versions.
3GPP
Release 16 49 3GPP TS 29.509 V16.0.0 (2019-06)
Annex D (informative):
Change history
Change history
Date Meeting TDoc CR Rev Cat Subject/Comment New
version
2017-10 CT4#80 C4-175268 Initial Draft.(Agreed Skeleton) 0.1.0
2017-10 CT4#80 C4-175394 Inclusion of pCR agreeds during CT4#80: C4-175269 and C4- 0.2.0
175270
2017-12 CT4#81 C4-176437 Inclusion of pCR agreeds during CT4#81: C4-176267, C4-176269, 0.3.0
C4-176426, C4-17427
2018-01 CT4#82 C4-181391 Inclusion of pCR agreeds during CT4#82: C4-181341, C4-181342, 0.4.0
C4-181343, C4-181344, C4-181345,C4-181346, C4-181347,C4-
181155
2018-03 CT4#83 C4-182434 Inclusion of pCRs agreeds during CT4#83: C4-182283 and C4- 0.5.0
182279
2018-03 CT#79 CP-180031 Presented for information 1.0.0
2018-04 CT4#84 C4-183516 Inclusion of pCRs agreed during CT4#84: C4-183309, C4-183313, 1.1.0
C4-183346, C4-183347 and C4-183448
2018-05 CT4#85 C4-184623 Inclusion of PCRs agreeds during CT4#83: C4-184219, C4-184220, 1.2.0
C4-184224, C4-184227, C4-184227, C4-184362, C4-184363, C4-
184367, C4-184368, C4-184370, C4-184376, C4-184380, C4-
184584, C4-184624
2018-06 CT#80 CP-181104 Presented for approval 2.0.0
2018-06 CT#80 Approved in CT#80. 15.0.0
2018-09 CT#81 CP-182059 0002 2 F Requester ID in Authentication Info 15.1.0
2018-09 CT#81 CP-182059 0003 1 F HTTP method in figure 5.2.2.2.2-1 (Note: clause 6.1.3.1 is not 15.1.0
included, already covered)
2018-09 CT#81 CP-182059 0004 4 F SoRProtection service operation 15.1.0
2018-09 CT#81 CP-182059 0010 1 F Adding TS 33.501 reference 15.1.0
2018-09 CT#81 CP-182059 0011 - F HTTP Custom Header 15.1.0
2018-09 CT#81 CP-182059 0013 1 F SUPI sends to AMF 15.1.0
2018-09 CT#81 CP-182068 0014 2 B 5G Trace for AUSF 15.1.0
2018-09 CT#81 CP-182013 0015 2 F Making Oauth 2.0 optional in OAS description 15.1.0
2018-09 CT#81 CP-182059 0016 1 F Editorial Corrections 15.1.0
2018-09 CT#81 CP-182059 0017 1 F Error code correction 15.1.0
2018-09 CT#81 CP-182059 0018 1 F Add support to EAP-TLS (Optional) 15.1.0
2018-09 CT#81 CP-182059 0019 - F Correcting Presentation of resources for AUSF API 15.1.0
2018-09 CT#81 CP-182059 0020 1 F Correcting confirmation message 15.1.0
2018-09 CT#81 CP-182059 0021 - F API version number update 15.1.0
2018-12 CT#82 C4-187253 0026 - F Remove the "supiOrSuci" in Confirmation Data 15.2.0
2018-12 CT#82 C4-187254 0027 - F Correcting Resource URI structure of the SoRProtection Service 15.2.0
2018-12 CT#82 C4-187359 0030 - F Cardinality 15.2.0
2018-12 CT#82 C4-187370 0031 - F Add supi and authResult to EapSession in OpenAPI definitions 15.2.0
2018-12 CT#82 C4-187478 0022 - F Requester ID not needed in initial request from AMF 15.2.0
2018-12 CT#82 C4-187479 0023 - F Delaying transmission of Kseaf 15.2.0
2018-12 CT#82 C4-187480 0024 1 F Correcting the reference to EAP-AKA' 15.2.0
2018-12 CT#82 C4-187481 0025 1 F Adding a reference to the Annex in the Specification 15.2.0
2018-12 CT#82 C4-187483 0028 1 F Error handling in AUSF 15.2.0
2018-12 CT#82 C4-187485 0029 1 F Add a reference to the IETF RFC 3748 on EAP Framework 15.2.0
2018-12 CT#82 C4-188060 0032 - F Base64 reference 15.2.0
2018-12 CT#82 C4-188109 0033 - F APIRoot Clarification 15.2.0
2018-12 CT#82 C4-188150 0034 - F Reference correction 15.2.0
2018-12 CT#82 C4-188251 0036 - F OpenAPI version number for Nausf_UEAuthentication service 15.2.0
2018-12 CT#82 C4-188494 0037 1 F OpenAPI version number for Nausf_SoRProtection 15.2.0
2018-12 CT#82 C4-188495 0038 1 F Correct "externalDocs" for Nausf_UEAuthentication OAS 15.2.0
2018-12 CT#82 C4-188497 0039 1 F Clarification on the 200 OK returned by AUSF in case of 15.2.0
authentication failure
2018-12 CT#82 C4-188547 0040 - F Secured packet in SorInfo 15.2.0
2018-12 CT#82 CP-183170 0035 2 Location Header in OpenAPI 15.2.0
2018-12 CT#82 CP-183172 0041 - F Alignement for Oauth scopes - Nausf_UEAuthentication 15.2.0
2018-12 CT#82 CP-183173 0042 - F Alignement for Oauth scopes - Nausf_SoRProtection 15.2.0
2018-12 CT#82 CP-183203 0043 - F externalDocs for Nausf_SoRProtection OpenAPI Annex 15.2.0
2019-03 CT#83 CP-190022 0047 1 F Mandatory HTTP status codes 15.3.0
2019-03 CT#83 CP-190022 0049 1 F SoR Protection response code alignment 15.3.0
2019-03 CT#83 CP-190022 0044 3 F Authentication Failure scenarios 15.3.0
3GPP
Release 16 50 3GPP TS 29.509 V16.0.0 (2019-06)
2019-03 CT#83 CP-190153 0046 7 F UE parameters update support (indicated as C4-190618 + C4- 15.3.0
190618_rev7I)
2019-03 CT#83 CP-19205 0050 1 F 3GPP TS 29.509 API version update 15.3.0
2019-06 CT#84 CP-191033 0051 - F Correct the expression of URI variables in 5g-aka- 15.4.0
confirmation resource
2019-06 CT#84 CP-191033 0053 2 F Storage of OpenAPI specification files 15.4.0
2019-06 CT#84 CP-191033 0056 - F AUSF Tracing Targeting a PEI 15.4.0
2019-06 CT#84 CP-191033 0055 1 F Determination of the Authentication Method 15.4.0
2019-06 CT#84 CP-191218 0059 4 F Add withdrawn API version Annex 15.4.0
2019-06 CT#84 CP-191033 0058 1 F Essential correction to add Copyright on OpenAPI 15.4.0
specifications
2019-06 CT#84 CP-191057 0054 1 F Non cacheable 501 response 16.0.0
2019-06 CT#84 CP-191057 0057 1 B UDM service discovery based on GroupID and/or RoutingID 16.0.0
2019-06 CT#84 CP-191223 0060 2 F 3GPP TS 29.509 API version update 16.0.0
3GPP