Content for TR 33.854 Word version: 17.1.0
6.2 Solution #2: UAS authentication and authorization using User Plane
6.2.1 Solution overview
6.2.2 Solution details
6.2.3 Solution evaluation
...
...
6.2 Solution #2: UAS authentication and authorization using User Plane p. 18
6.2.1 Solution overview p. 18
This solution addresses the key issue #1. It introduces a new 3GPP Application Function placed in user-plane (UAS AF) which validates that the UAV/networked-UAVC (networked-UAVC is the UAVC connected via 3GPP) has a valid UAV subscription and includes relevant UAV subscription information and UAV application information to be sent to the USS/UTM to support the USS/UTM for the authentication and authorization of the UAV/networked-UAVC. Throughout this key issue, unless otherwise specified, "UAVC" is used for "networked-UAVC".
This solution assumes that each UAV or UAVC is provisioned with a PLMN UE ID and the corresponding credentials to be used in primary authentication by the PLMN as a normal UE. Also, the UEs are provisioned with a CAA level ID and corresponding credentials to be used in UAS authentication and authorization (UAA) by USS/UTM. The credentials used in UAS A&A and A&A method are out of 3GPP scope.
The solution allows the execution of A&A procedure between UAV and USS/UTM where 3GPP provides communication between UAV and USS/UTM. For this communication, first the UAV needs to execute primary authentication, so the UAV and 3GPP execute mutual authentication. Then when the UAV wants to get UAV related service, 3GPP system allows the UAV to communicate with the UAS AF located in the inside of the operator network. The UAS AF and the USS/UTM communicates via NEF framework which requires mutual authentication. As a result, there is a hop-by-hop mutual authentication between UAV and USS/UTM during UUAA procedure. The A&A protocol is out of 3GPP scope and this protocol may provide additional mutual authentication between UAV and USS/UTM using their credentials which are out of 3GPP scope.
Also, this solution includes an authorization revocation mechanism that allows the authorization revocation triggered by USS/UTM.
6.2.2 Solution details p. 19
6.2.2.0 General p. 19
The authentication and authorization procedures for 5GS and EPS are presented in clause 6.2.2.1 and 6.2.2.2, respectively.
6.2.2.1 Procedure for 5GS p. 19
Figure 6.2.2.1-1: UAV Authentication and Authorization procedure for 5GS
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
Primary authentication is performed.
Step 2.
A PDU session is established for the UE's A&A request. The connection is allowed only between UAV/UAVC and UAS AF.
Step 3.
UAV/ UAVC sends the request for authentication and authorization to the UAS AF over the user plane, e.g. including UAV/UAVC identity, USS/UTM identity (if available), and application level information, transparent to 3GPP and out of 3GPP scope, to be used by the USS/UTM when authenticating the UAV.
Step 4.
The UAS AF gets the relevant subscription information from PCF or UDM with support from existing BSF functionality via SBA interfaces.
Step 5.
UAS AF checks if the UAV has a valid aerial subscription based on the subscription information received from PCF or UDM. The UAS-AF learns the 3GPP UAV ID/GPSI from the BSF lookup and adds it to the CAA-Level UAV-ID and application level information that is forwarded to the USS/UTM.
If the check is successful, the UAS AF determines the USS/UTM serving the UAV/UAVC based on the USS/UTM identity provided in the request in Step 3 and the predefined list stored in UAS AF with valid USS/UTM identities including URLs to corresponding requests. If the requested identity is not in the list, the request from the UAV will be rejected. Otherwise, UAS AF sends A&A request towards the UTM/USS. The UAS AF provides 3GPP identities/information for the UAV including the GPSI and the CAA-Level UAV ID and any application level information the UAV has provided to the 3GPP system to the USS/UTM needed for further interaction between USS/UTM and 5GS regarding the PDU session. The request can contain an indication about the used mobile operator and 3GPP UAV/UAVC identity. Additionally, it forwards also the UAV/UAVC specific information received in the UAS A&A request. For the communication between UAS AF and USS/UTM, the NEF or the Common API framework (CAPIF) is used.
Step 6.
An authentication and authorization procedure is executed between UAV/UAVC and USS/UTM. UAS AF relays the messages in this A&A procedure providing API's, which use well-known web security mechanisms such as HTTPS, for the UAV-application and USS/UTM. USS/UTM considers the combined information from the UAV/UAVC and from the mobile network operator of the UAV/UAVC while performing the procedure. Note that if the information sent to the USS/UTM before this step is enough for the authentication & authorization procedure, there may be no need for extra message exchange between the UAV/UAVC and USS/UTM.
Step 7.
USS/UTM sends UAS A&A result to UAS AF.
If the A&A result is successful, then USS/UTM may provide application specific information to be used for secure communication establishment between UAV and UTM/USS. This information is transparent to the network and the content is out of 3GPP scope. The network relays this information from the UTM/USS to the UAV.
If the A&A is unsuccessful, USS/UTM may inform the UAS AF about the action to take e.g. whether the PDU session established in Step 2 will be terminated.
Step 8.
The UAS AF sends the response to the UAV.
Step 9.
If the result of the A&A in Step 6 is successful, the UAS AF informs the SMF to modify the PDU session established in Step 2 such that the UAV/UAVC can communicate to the USS/UTM.
If A&A is not successful in Step 6, the UAS AF may inform the SMF to terminate the PDU session established in Step 2 according to the response from USS/UTM in Step 7.
6.2.2.2 Procedure for EPS p. 21
Figure 6.2.2.2-1: UAV Authentication and Authorization procedure for EPS
(⇒ copy of original 3GPP image)
(⇒ copy of original 3GPP image)
Step 1.
Attach and a PDN connection activation procedures are performed. As the UAV has a subscription indicating UAV capability the PCRF generates a PCC rule indicating UAV application and header enrichment policy.
Step 2.
UAV sends UAS A&A request to the UAS AF.
Step 3.
PGW detects the UAV application traffic and adds UAV subscription information.
Step 4.
UAS AF checks if the UAV has a valid aerial subscription based on the subscription information received from the PGW.
If the check is successful, the UAS AF based on the UTM/USS identity, looks up the corresponding UTM/USS URL and triggers a request towards the UTM/USS. If the check is unsuccessful a response is sent to the UAV rejecting the request. The UAS AF can include information to the UTM/USS needed for further interaction between UTM/USS using network APIs and EPS regarding the PDU session.
Step 5.
UTM/USS performs authentication and authorization steps which are transparent to the network. In this communication, the UAS AF and PGW relay the traffic between UAV and UTM/USS.
Step 6.
If the A&A in step 5 is successful, UTM/USS triggers a accept response to UAS AF acknowledging the request including an application specific information such as a security context to be used in the establishment of secure connection between UAV and UTM/USS. The transfer of this information is transparent to the network and the content of it is out of 3GPP scope.
If the A&A is un-successful, a response is sent to the UAV rejecting the request.
Step 7.
The UAS AF sends the response to the UAV.
Step 8.
UAV triggers a set-up of a secure connection to UTM/USS e.g. using the information received in step 7.
6.2.2.3 Authorization revocation mechanism p. 21
When the USS/UTM wants to trigger authorization revocation, it calls the NEF API (AsSessionWithQoS) used to activate, modify, and revoke policies for specific data flows on a specific PDU-session/PDN-connection. UAS AF provides related information needed by the USS/UTM to call that API, during the authentication and authorization procedure.
During the authentication and authorization procedure, UAS AF provides the UE-IP of the UAV to the USS/UTM. After successful authentication and authorization by the USS/UTM, the USS/UTM calls AsSessionWithQoS to activate the authorized policies for the PDU-session and then waits for a notification on that they have been successfully enforced. Then the USS/UTM sends the A&A result back to the UAS-AF which will forward the result to the UAV.
6.2.3 Solution evaluation p. 22
This solution fully addresses key issue #1 having no effect on the current NAS procedures and UAV UE proposing a UP solution.
This solution provides a user plane solution while TR 23.754 concludes on using control plane based UUAA procedures.
This solution requires a new function (UAS AF) that requires updates on AMF and PCF for the subscription information requests.
It uses web-based interface for the communication between UAS AF and USS/ UTM.
