This subclause specifies support for optional to use secondary authentication between the UE and an external data network (DN).
The EAP framework specified in RFC 3748  shall be used for authentication between the UE and a DN-AAA server in the external data network. The SMF shall perform the role of the EAP Authenticator. In the non-roaming scenario, the SMF shall perform the role of EAP Authenticator. And In the local break out scenario, the V-SMF of visited nework shall perform the role of EAP Authenticator. In the Home Routed deployment scenario, the H-SMF shall perform the role of the EAP Authenticator and the V-SMF shall transport the EAP messages exchanged between the UE and H-SMF. It shall rely on the external DN-AAA server to authenticate and authorize the UE's request for the establishment of PDU sessions.
Between the UE and the SMF, EAP messages shall be sent in the SM NAS message. This message is received at the AMF over N1 and delivered to the SMF over N11 using either the Nsmf_PDUSession_CreateSMContext service operation or the Nsmf_PDUSession_Update SM Context service operation, as specified in TS23.502 . The SMF that takes the role of the EAP authenticator communicates with the external DN-AAA over N4 and N6 via the UPF.
The SMF invokes the Namf_Communication_N1N2MessageTransfer service operation to transfer the N1 NAS message containing the EAP message, towards the UE via the AMF.
Following clauses describe the procedures for initial Authentication and Re-Authentication with the external DN-AAA server.
Figure 11.1.2-1: Initial EAP Authentication with an external AAA server
This procedure concerns both roaming and non-roaming scenarios. In the non-roaming case, the V-SMF is not involved. In the HR roaming case, the V-SMF shall proxy the signalling between the AMF in the VPLMN and the H-SMF in the HPLMN. In the LBO roaming case, only one SMF in VPLMN is involved.
The following procedure is based on subclauses 126.96.36.199.2, 188.8.131.52.1 and 184.108.40.206 in TS 23.502.
The UE initiates establishment of a new PDU Session by sending a NAS message containing a PDU Session Establishment Request within the N1 SM container, slice information (identified by S-NSSAI) , PDU session ID and the PDN it would like to connect to (identified by DNN).
The PDU Session Establishment Request may contain SM PDU DN Request Container IE containing information for the PDU session authorization by the external DN.
The AMF selects a V-SMF and sends either Nsmf_PDUSession_CreateSMContext Request or Nsmf_PDUSession_UpdateSMContext Request with the N1 SM container as one of its payload. It also forwards SUPI PDU Session ID, the received S-NSSAI, and the DNN.
The H-SMF obtains subscription data from the UDM for the given SUPI obtained from the AMF in step 5. The SMF checks the subscription data whether the secondary authentication is required and whether the UE request is allowed according to the user subscription and local policies. If not allowed, the H-SMF will reject UE's request via SM-NAS signalling and skip rest of the procedure. If secondary authentication is required, the SMF may also check whether the UE has been authenticated and/or authorized by the same DN, as indicated DNN in step 5, or the same AAA server in a previous PDU session establishment. The SMF may skip steps 8 to 15 if positive.
The H-SMF shall trigger EAP Authentication to obtain authorization from an external DN-AAA server. If there is no existing N4 session, the H-SMF selects a UPF and establishes an N4 Session with it. The H-SMF notifies the DN-AAA server with the GPSI, if available, and the IP address(es) of the UE allocated to the PDU Session if the PDU session is of IP PDU type or the MAC address if the PDU session is of Ethernet PDU type.
The UE shall send an EAP Response/Identity message contained within the SM PDU DN Request Container of a NAS message. The SM PDU DN Request Container includes its DN-specific identity complying with Network Access Identifier (NAI) format and PDU session ID.
To avoid the additional round-trip in steps 9 and 10, the secondary authentication identity may be sent by the UE in step 4.
If there is no existing N4 session, the H-SMF selects a UPF and establishes an N4 Session with it. The SM PDU DN Request Container, if provided by the UE, is forwarded to the UPF. The H-SMF identifies the DN AAA server based on the SM PDU DN Request Container provided by the UE and on local configuration.
The DN AAA server and the UE shall exchange EAP messages, as required by the EAP method, contained in the SM PDU DN Request Containers. In addition, it may send additional authorization information as defined in TS 23.501, clause 5.6.6.
This completes the authentication procedure at the SMF. The SMF may save the DN-specific ID and DNN (or DN's AAA server ID if available) in a list for successful authentication/authorization between UE and an SMF. Alternatively, the SMF may update the list in UDM.
If the authorization is successful, PDU Session Establishment proceeds further starting at step 7a of Figure 220.127.116.11.1-1 in TS 23.502.
The V-SMF sends Namf_Communication_N1N2MessageTransfer to the AMF as in step 11 of Figure 18.104.22.168.1-1 in TS 23.502. This message shall include EAP Success to be sent to the UE within the NAS SM PDU Session Establishment Accept message.
Figure 11.1.3-1: EAP Re-Authentication with an external AAA server
This procedure concerns both roaming and non-roaming scenarios. In the non-roaming and LBO roaming cases, only one SMF is involved. In the HR roaming case, the V-SMF shall proxy the signalling between the AMF in the VPLMN and the H-SMF in the HPLMN.
Secondary Authentications has been established according to procedures specified in clause 11.1.2, Initial EAP Authentication with an external AAA server.
Secondary Re-authentication may either be initiated by SMF or the external DN/AAA server. If Re-authentication is initiated by SMF, the procedure proceeds with step 4 (skipping steps 4a and 4b). If Re-authentication is initiated by the external DN/AAA server, the procedure proceeds with the alternative steps 4a and 4b.
The DN AAA shall send a Secondary Re-Authentication request to UPF and the UPF forwards to SMF. The Secondary Re-authentication request contains the GPSI, if available, and the IP/MAC address of the UE allocated to the PDU Session and the MAC address if the PDU session is of Ethernet PDU type.
The SMF forwards the EAP Response/Identity to UPF, selected during initial authentication, over N4 interface.
This establishes an end-to-end connection between the SMF and the external DN-AAA server for EAP exchange.
In the 5G system, the Network Functions securely expose capabilities and events to 3rd party Application Functions via NEF. The NEF also enable secure provision of information in the 3GPP network by authenticated and authorized Application Functions.
Requirements on security aspects of NEF are captured in clause 22.214.171.124.
For authentication between NEF and an Application Function that resides outside the 3GPP operator domain, mutual authentication based on client and server certificates shall be performed between the NEF and AF using TLS.
Certificate based authentication shall follow the profiles given in TS 33.210, clause 6.2. The structure of the PKI used for the certificate is out of scope of the present document.
TLS shall be used to provide integrity protection, replay protection and confidentiality protection for the interface between the NEF and the Application Function. The support of TLS is mandatory.
Security profiles for TLS implementation and usage shall follow the provisions given in clause 6.2 of TS 33.210.
After the authentication, NEF determines whether the Application Function is authorized to send requests for the 3GPP Network Entity. The NEF shall authorize the requests from Application Function using OAuth-based authorization mechanism, the specific authorization mechanisms shall follow the provisions given in RFC 6749 .
When the NEF supports CAPIF for external exposure as specified in clause 126.96.36.199 of TS 23.501, then CAPIF core function shall choose the appropriate CAPIF-2e security method as defined in the subclause 6.5.2 in TS 33.122 for mutual authentication and protection of the NEF - AF interface.