Network Slice-specific Authentication and Authorization Function

Description

The Network Slice-specific Authentication and Authorization Function (NSSAAF) is a dedicated logical function within the 5G Core Network (5GC) specified from 3GPP Release 16. Its primary role is to facilitate the Network Slice-Specific Authentication and Authorization (NSSAA) procedure. The NSSAAF does not perform the authentication itself but acts as a relay and orchestrator between the Access and Mobility Management Function (AMF) within the operator's trust domain and external Authentication, Authorization, and Accounting (AAA) servers that belong to the tenant or provider of a specific network slice. This architecture is fundamental to enabling multi-party and multi-domain network slicing scenarios.

Operationally, the NSSAAF receives NSSAA requests from the AMF via the service-based interface Nnssaaf_NSSAA. This request includes the UE's identity and the identifier of the requested network slice (S-NSSAI). The NSSAAF then initiates a dialogue with the appropriate external AAA server, which is identified based on the S-NSSAI. The communication with the external AAA server occurs over the N33 reference point. The NSSAAF transparently relays Extensible Authentication Protocol (EAP) packets between the UE (which is the EAP peer) and the external AAA server (which is the EAP server). The UE and the external AAA server conduct a full EAP authentication method (e.g., EAP-AKA', EAP-TLS), with the NSSAAF and AMF simply passing the packets. The NSSAAF is responsible for mapping the EAP session to the correct UE and AMF context.

The NSSAAF's key responsibilities include managing the state of the NSSAA procedure, enforcing timeouts, and translating the final result from the external AAA server (EAP Success/Failure) into a 3GPP-defined NSSAA result sent to the AMF. It also handles potential error conditions from the external AAA server. The function can be implemented as a standalone Network Function (NF) or can be combined with another NF, such as the Authentication Server Function (AUSF), depending on vendor implementation and network deployment choices. Its design emphasizes neutrality to the specific EAP method used, allowing slice tenants to employ the authentication mechanism that best suits their security requirements.

Purpose & Motivation

The NSSAAF was created to operationalize the concept of slice-specific authentication introduced with NSSAA. Without a dedicated function to manage the interaction with external AAA systems, the AMF would need to directly interface with a potentially unlimited number of tenant-specific AAA servers, each with different protocols and security requirements. This would create immense complexity, scalability issues, and security risks for the core network operator.

The NSSAAF solves this by providing a standardized, secure, and controlled intermediary point. It abstracts the complexity of external AAA interactions from the AMF, allowing the AMF to handle mobility and session management while delegating slice-specific security decisions. This separation of concerns is a classic architectural principle that enhances modularity and security. Furthermore, the NSSAAF provides a single point in the operator's network where policies regarding external connectivity (e.g., firewall rules, traffic policing for AAA messages) can be enforced. Its creation was motivated by the need to make network slicing practically deployable for enterprise and vertical use cases, where the slice tenant demands control over access authentication without requiring deep integration of their AAA systems into the MNO's core.

Key Features

• Acts as a proxy/relay for EAP messages between the UE (via AMF) and an external AAA server
• Provides a standardized service-based interface (Nnssaaf_NSSAA) towards the AMF
• Utilizes the N33 reference point for communication with external AAA servers
• Manages the state and context of ongoing slice-specific authentication procedures
• Translates between EAP protocol results and 3GPP-specific NSSAA result codes
• Can be deployed as a standalone NF or co-located with other NFs like the AUSF

Evolution Across Releases

Defining Specifications