17 Interworking with NSS-AAA (Diameter)

29.5613GPP5G SystemInterworking between 5G Network and external Data NetworksRelease 17Stage 3TS

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

17.1 Diameter procedures

17.1.1 General

The Network Slice Specific Authentication and Authorization procedure is triggered for a network slice requiring Network Slice Specific Authentication and Authorization with an NSS-AAA server which may be hosted by the H-PLMN operator or a third party which has a business relationship with the H-PLMN. An AAA Proxy (AAA-P) in the HPLMN may be involved e.g. if the NSS-AAA Server belongs to a third party.

17.1.2 Diameter Authentication and Authorization

Diameter Authentication and Authorization shall be used according to IETF RFC 7155 [23]. In 5G, multiple authentication methods using Extensible Authentication Protocol (EAP) may be used such as EAP-TLS (see IETF RFC 5216 [11]), EAP-TTLS (see IETF RFC 5281 [37]). The NSSAAF or AAA-P shall support Diameter EAP application as specified in IETF RFC 4072 [25].

The NSSAAF or AAA-P and the NSS-AAA shall advertise the support of the Diameter NASREQ and EAP applications by including the value (1 and 5) of the application identifier in the Auth-Application-Id AVP (as specified in IETF RFC 4072 [25]) and the value of the 3GPP (10415) in the Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands as specified in IETF RFC 6733 [24], i.e. as part of the Vendor-Specific-Application-Id AVP.

The Diameter client function may reside in an NSSAAF. When the NSSAAF receives Nnssaaf_NSSAA_Authenticate request from AMF, the Diameter client function shall send the authentication information with network slice information to a NSS-AAA server directly or via an AAA-P (if AAA-P is used).

The NSS-AAA server performs authentication and authorization for the requested network slice information. When the Nnssaaf receives a positive response from the NSS-AAA server or AAA-P (if AAA-P is used), it shall complete the network slice specific authentication procedure. If negative response or no response is received, the NSSAAF shall reject the network slice specific authentication procedure with a suitable cause code.

The NSS-AAA may revoke the authorization for the network slice, see details in clause 17.2.2. NSS-AAA may initiate re-authentication and re-authorization, see details in clause 17.2.3.

17.2 Message flows for network slice specific authentication

17.2.1 Authentication and Authorization procedures

For network slice specific authentication and authorization, when the NSSAAF receives Nnssaaf_NSSAA_Authenticate request from AMF, it shall send a Diameter DER message with GPSI in Calling-Station-Id or External-Identifier attribute and network slice information in 3GPP-S-NSSAI attribute to a NSS-AAA server directly or via AAA-P if AAA-P is involved. Upon receipt of the DER message, the DN-AAA server shall respond with an DEA message. Multi-round authentication using the DEA and DER messages may be used. The NSS-AAA server finally authenticates and authorizes the user and the network slice by replying with a Diameter DEA message.

For re-authentication and re-authorization, the NSSAAF shall send a DER message to the NSS-AAA server directly or via AAA-P if AAA-P is used and the NSS-AAA server shall respond with a DEA message. Multi-round authentication using the DEA and DER messages may be used. The NSS-AAA server finally authenticates and authorizes the user and the network slice by replying with a Diameter DEA message.

If the network slice specific authentication is not required, the NSSAAF shall send a Diameter STR message to the NSS-AAA server directly or via AAA-P if AAA-P is involved. The NSS-AAA server shall reply with a Diameter STA message.The following figure 17.2.1-1 is an example message flow to show the procedure of Diameter Authentication and Authorization between an AMF and a NSS-AAA server:

1. AMF decides to trigger the start of the Network Slice Specific Authentication and Authorization procedure.

2. The AMF may send an EAP Identity Request in a NAS Network Slice-Specific Authentication Command message.

3. The UE provides the EAP Identity Response in a NAS Network Slice-Specific Authentication Complete message towards the AMF.

4. The AMF sends Nnssaaf_NSSAA_Authenticate Request to the NSSAAF including the authentication/authorization information.

5-6. If the AAA-P is present (e.g. because the NSS-AAA belongs to a third party and the operator deploys a proxy towards third parties), the NSSAAF sends the DER message to the NSS-AAA via the AAA-P to forward the authentication/authorization information, otherwise the NSSAAF sends the DER message directly to the NSS-AAA.

7-14. The NSS-AAA responds with the DEA message to the NSSAAF directly or via the AAA-P. The authentication/authorization information is further transferred to UE via AMF by Nnssaaf_NSSAA_Authenticate service and NAS MM Transport message. UE responds to the received authentication/authorization data and such information is transferred in NAS Network Slice-Specific Authentication Complete message and Nnssaaf_NSSAA_Authenticate service, then finally sent to the NSS-AAA by the NSSAAF, via the AAA-P if the AAA-P is used, in the DER message.

NOTE: Step 7 to step 14 can be repeated depending on the authentication/authorization mechanism used (e.g. EAP-TLS).

15-16. If the AAA-P is used, the NSS-AAA sends a DEA message with the final result of authentication/authorization to the NSSAAF via the AAA-P, otherwise the NSS-AAA sends the DEA message directly to the NSSAAF.

17. The NSSAAF sends a Nnssaaf_NSSAA_Authenticate Response with the final result of authentication/authorization information to the AMF.

18. The AMF transfers the final result of authentication/authorization information in a NAS Network Slice-Specific Authentication Result message to the UE.

Figure 17.2.1-1: Network slice specific authentication and Authorization procedure (Diameter)

17.2.2 NSS-AAA initiated revocation of network slice authorization

The NSS-AAA server may send a Diameter ASR message to the NSSAAF directly or via AAA-P (if AAA-P is used) asking for revocation of network slice authorization. On receipt of the ASR message from the NSS-AAA server, the NSSAAF shall check whether the NSS-AAA server is authorized to request the revocation by verifying the local configuration of the address of the NSS-AAA server per S-NSSAI, if successful, the NSSAAF shall release the corresponding resources, interact with its succeeding Network Function AMF which is got from the UDM by Nudm_UECM_GET service operation with GPSI and reply with a Diameter ASA message. It is not necessary for the NSSAAF to wait for the response (i.e. Nudm_UECM_GET or Nnssaaf_NSSAA_Notify response) from its succeeding Network Function before sending the ASA message to the NSS-AAA server or AAA-P.

NOTE: In the Diameter ASR request, the Origin-Host AVP with the FQDN/domain format indicates the address of the NSS-AAA server for NSSAAF check.

Figure 17.2.2-1 is an example message flow to show the procedure of NSS-AAA initiated revocation of network slice authorization. If the AAA-P is not used, the ASR and ASA messages are exchanged between the NSS-AAA and the NSSAAF.

Figure 17.2.2-1: NSS-AAA initiated revocation of network slice authorization with Diameter

17.2.3 NSS-AAA initiated re-authentication and re-authorization

The NSS-AAA server may send a Diameter RAR message to the NSSAAF directly or via AAA-P (if AAA-P is used) asking for re-authentication and re-authorization. On receipt of the RAR message from the NSS-AAA server, the NSSAAF shall check whether the NSS-AAA server is authorized to request the re-authentication and re-authorization by verifying the local configuration of the address of the NSS-AAA server per S-NSSAI, if successful, the NSSAAF shall interact with its succeeding Network Function AMF which is got from the UDM by Nudm_UECM_GET service operation with GPSI and reply with a Diameter RAA message. It is not necessary for the NSSAAF to wait for the response (i.e. Nudm_UECM_GET or Nnssaaf_NSSAA_Notify response) from its succeeding Network Function before sending the RAA message to the NSS-AAA server or AAA-P.

NOTE: In the Diameter RAR request, the Origin-Host AVP with the FQDN/domain format indicates the address of the NSS-AAA server for NSSAAF check.

After replying Nnssaaf_NSSAA_Notify response, the AMF shall start authentication and authorization procedure as described in clause 17.2.1. The Auth-Request-Type in the DER is set to "AUTHORIZE_AUTHENTICATE".

Figure 17.2.3-1 is an example message flow to show the procedure of NSS-AAA initiated re-authentication and re-authorization. If the AAA-P is not used, the RAR and RAA messages are exchanged between the NSS-AAA and the NSSAAF.

Figure 17.2.3-1: NSS-AAA initiated re-authentication and re-authorization with Diameter

17.3 Specific AVPs

There is no specific AVP defined in the present release.

17.4 re-used AVPs

17.4.1 General

Information defined in clause 12.4.0 are re-used for network slice specific authentication with the following differences:

– NSSAAF replaces SMF.

– IP, Ethernet and PDU session related descriptions and AVPs are not applicable.

– Additional detailed information needed for network slice specific authentication are described below.

Table 17.4-1: Additional information needed for network slice specific authentication

Attribute Name	AVP Code	Section defined	Value Type (NOTE 2)	AVP Flag rules (NOTE 1)				May Encr.	Applicability
				Must	May	Should not	Must not
3GPP-S-NSSAI	200	16.3.1 (NOTE 3)	UTF8String	V	P		M	Y
NOTE 1: The AVP header bit denoted as ‘M’, indicates whether support of the AVP is required. The AVP header bit denoted as ‘V’, indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETF RFC 6733 [24]. NOTE 2: The value types are defined in IETF RFC 6733 [24]. NOTE 3: The use of Radius VSA as a Diameter vendor AVP is described in Diameter NASREQ (IETF RFC 7155 [23]) and the P flag may be set.

17.4.2 Use of the Supported-Features AVP

The Supported-Features AVP is used during the network slice specific authentication procedure to inform the destination host about the required and optional features that the origin host supports. The client shall, in the first request in a Diameter session indicate the set of supported features. The server shall, in the first answer within the Diameter session indicate the set of features that it has in common with the client and that the server shall support within the same Diameter session. Any further command messages shall always be compliant with the list of supported features indicated in the Supported-Features AVPs during session establishment. Features that are not advertised as supported shall not be used to construct the command messages for that Diameter session. Unless otherwise stated, the use of the Supported-Features AVP shall be compliant with the requirements for dynamic discovery of supported features and associated error handling on the Cx reference point as defined in clause 7.2.1 of 3GPP TS 29.229 [41].

The base functionality is the 3GPP Rel-16 standard and a feature is an extension to that functionality. If the origin host does not support any features beyond the base functionality, the Supported-Features AVP may be absent in the DER command. As defined in clause 7.1.1 of 3GPP TS 29.229 [41], when extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF.

As defined in 3GPP TS 29.229 [41], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. The Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined, the Feature-List-ID AVP shall differentiate those lists from one another.

On receiving an initial request application message, the destination host shall act as defined in clause 7.2.1 of 3GPP TS 29.229 [41].

Once the NSSAAF or AAA-P and NSS-AAA have negotiated the set of supported features during session establishment, the set of common features shall be used during the lifetime of the Diameter session.

The table below defines the features applicable for the network slice specific authentication, for the feature lists with a Feature-List-ID of 1.

Table 17.4.2-1: Features of Feature-List-ID 1

Feature bit

Feature

M/O

Description

Feature bit: The order number of the bit within the Feature-List AVP where the least significant bit is assigned number "0".

Feature: A short name that can be used to refer to the bit and to the feature, e.g. "5GC".

M/O: Defines if the implementation of the feature is mandatory ("M") or optional ("O") in this 3GPP Release.

Description: A clear textual description of the feature.

17.5 Specific Experimental-Result-Code AVP

There is no specific experimental result code AVP defined in the present release.

17.6 Diameter messages

17.6.1 General

Diameter messages as defined in clause 12.6 are re-used for network slice specific authentication with the following differences:

– NSSAAF or AAA-P replaces SMF.

– IP, Ethernet and PDU session related descriptions and AVPs are not applicable.

– Diameter commands for accounting function (ACR and ACA) are not applicable.

– AAR and AAA commands are not applicable.

– 3GPP-S-NSSAI is included in the DER command.

– the address of NSS-AAA server is included in the Origin-Host AVP in the ASR and RAR command

NOTE: The presence of 3GPP-S-NSSAI in the DER command is optional but it is mandatory for the NSSAAF or AAA-P to include it for the network slice specific authentication.