3GPP 23.501 v20.2.0 — the document's own text
5.6.6 Secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session
Taught in 12. The connection to a data network (The 5G system architecture, in depth), 5. The connection, and what is promised on it (The 5G system architecture, overview).
At PDU Session Establishment to a DN:
NOTE 1: the DN-AAA server may belong to the 5GC or to the DN.
- If the UE provides authentication/authorization information corresponding to a DN-specific identity during the Establishment of the PDU Session and the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required based on the SMF policy associated with the DN, the SMF passes the authentication/authorization information of the UE to the DN-AAA server via the UPF if the DN-AAA server is located in the DN. If the SMF determines that Secondary authentication/authorization of the PDU Session Establishment is required but the UE has not provided a DN-specific identity as part of the PDU Session Establishment request, the SMF requests the UE to indicate a DN-specific identity using EAP procedures as described in TS 33.501 [29]. If the Secondary authentication/authorization of the PDU Session Establishment fails, the SMF rejects the PDU Session Establishment.
NOTE 2: If the DN-AAA server is located in the 5GC and reachable directly, then the SMF may communicate with it directly without involving the UPF.
- The DN-AAA server may authenticate/authorize the PDU Session Establishment.
- When DN-AAA server authorizes the PDU Session Establishment, it may send DN Authorization Data for the established PDU Session to the SMF. The DN authorization data for the established PDU Session may include one or more of the following:
- A DN Authorization Profile Index which is a reference to authorization data for policy and charging control locally configured in the SMF or PCF.
- a list of allowed MAC addresses for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
- a list of allowed VLAN tags for the PDU Session; this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
- VLAN handling information (e.g. the C-TAG to be inserted or removed, S-TAG to be inserted or removed); this shall apply only for PDU Session of Ethernet PDU type and is further described in clause 5.6.10.2.
- DN authorized Session AMBR for the PDU Session. The DN Authorized Session AMBR for the PDU Session takes precedence over the subscribed Session-AMBR received from the UDM.
- Framed Route information (see clause 5.6.14) for the PDU Session.
- L2TP information, such as LNS IP address and/or LNS host name, as described in TS 29.561 [132].
SMF policies may require DN authorization without Secondary authentication/authorization. In that case, when contacting the DN-AAA server for authorization, the SMF provides the GPSI of the UE if available.
Such Secondary authentication/authorization takes place for the purpose of PDU Session authorization in addition to:
- The 5GC access authentication handled by AMF and described in clause 5.2.
- The PDU Session authorization enforced by SMF with regards to subscription data retrieved from UDM.
Based on local policies the SMF may initiate Secondary authentication/authorization at PDU Session Establishment. The SMF provides the GPSI, if available, in the signalling exchanged with the DN-AAA during Secondary authentication/authorization.
After the successful Secondary authentication/authorization, a session is kept between the SMF and the DN-AAA.
The UE provides the authentication/authorization information required to support Secondary authentication/authorization by the DN over NAS SM.
If a UE is configured with DNNs, which are subject to secondary authentication/authorization, the UE stores an association between the DNN and corresponding credentials for the secondary authentication/authorization.
NOTE 3: How the UE is aware that a DNN is subject to secondary authentication/authorization (e.g. based on local configuration) is out of scope of this specification.
The UE may support remote provisioning of credentials for secondary authentication/authorization, as specified in clause 5.39.
A UE that supports to be provisioned with the credentials used for secondary authentication/authorization over UP remote provisioning shall use connectivity over an S-NSSAI/DNN which can access the provisioning server to establish a PDU session for remote provisioning as defined in clause 5.39.
NOTE 4: The credentials for secondary authentication/authorization are not specified.
SMF policies or subscription information (such as defined in Table 5.2.3.3.1 of TS 23.502 [3]) may trigger the need for SMF to request the Secondary authentication/authorization and/or UE IP address / Prefix from the DN-AAA server.
When SMF adds a PDU Session Anchor (such as defined in clause 5.6.4) to a PDU Session Secondary authentication/authorization is not carried out, but SMF policies may require SMF to notify the DN when a new prefix or address has been added to or removed from a PDU Session or N6 traffic routing information has been changed for a PDU Session.
When SMF gets notified from UPF with the addition or removal of MAC addresses to/from a PDU Session, the SMF policies may require SMF to notify the DN-AAA server.
Indication of PDU Session Establishment rejection is transferred by SMF to the UE via NAS SM.
If the DN-AAA sends DN Authorization Data for the authorized PDU Session to the SMF and dynamic PCC is deployed, the SMF sends the PCF the DN authorized Session AMBR and/or DN Authorization Profile Index in the DN Authorization Data for the established PDU Session.
If the DN-AAA sends DN Authorization Profile Index in DN Authorization Data to the SMF and dynamic PCC is not deployed, the SMF uses the DN Authorization Profile Index to refer the locally configured information.
NOTE 5: DN Authorization Profile Index is assumed to be pre-negotiated between the operator and the administrator of DN-AAA server.
If the DN-AAA does not send DN Authorization Data for the established PDU Session, the SMF may use locally configured information.
At any time, a DN-AAA server may revoke the authorization for a PDU Session or update DN Authorization Data for a PDU Session. According to the request from DN-AAA server, the SMF may release or update the PDU Session. See clause 5.6.14 when the update involves Framed Route information.
At any time, a DN-AAA server or SMF may trigger Secondary Re-authentication procedure for a PDU Session established with Secondary Authentication as specified in clause 11.1.3 of TS 33.501 [29].
During Secondary Re-authentication/Re-authorization, if the SMF receives from DN-AAA the DN authorized Session AMBR and/or DN Authorization Profile Index, the SMF shall report the received value(s) to the PCF.
The procedure for secondary authentication/authorization by a DN-AAA server during the establishment of a PDU Session is described in clause 4.3.2.3 of TS 23.502 [3].
The support for L2TP on N6 is further specified in clause 5.8.2.16 and the procedure for establishment of L2TP tunnelling on N6 for a PDU Session is described in clause 4.3.2.4 of TS 23.502 [3].
NOTE 6: The L2TP Tunnel information sent to the SMF can, for example, be provisioned in the DN-AAA server per DNN/S-NSSAI or per SUPI or GPSI.