This annex describes the authentication procedure, using EAP-TLS as an example, for Non-5G Capable (N5GC) devices behind Residential Gateways (RGs) in private networks or in isolated deployment scenarios (i.e., roaming is not considered) with wireline access. The registration procedure of N5GC devices behind Cable RGs is described in clause 4.10a of TS 23.316.
N5GC devices lack some key 5G capabilities, including NAS and the derivation of 5G key hierarchy. Those devices exist in wireline networks and need to be able to access the converged 5G core. The authentication of N5GC devices can be based on additional EAP methods other than EAP-AKA'. The procedure in O.3 uses EAP-TLS as in Annex B as an example, but it differs from the Annex B in the following:
the W-AGF creates the registration request on behalf of the N5GC device,
5G related parameters (including ngKSI and ABBA) are not sent to the N5GC device. When received from the AMF, these paramters are ignored by the W-AGF, and
Neither the N5GC device nor the AUSF derive any 5G related keys after EAP authentication.
Figure O.3-1 shows the details of the authentication procedure as part of the initial registration procedure specified in clause 4.10a of TS 23.316 following the principles listed in clause O.2. It uses EAP-TLS as an example, but other EAP methods can also be supported. The W-AGF acts on behalf of the N5GC device during the registration process. The link between the N5GC device and the RG, and between the RG and the W-AGF can be any data link (L2) that supports EAP encapsulation.
[not reproduced yet]
Figure O.3-1: Registration and authentication of a non-5G capable device to the 5GC
In the following, the procedure for registration and authentication of an N5GC device to the 5GC is described:
The W-AGF initiates the EAP authentication procedure by sending an EAP request/Identity to the N5GC device via the RG, which acts as an L2 bridge device and forwards the ethernet frame to the N5GC device. The EAP message is encapsualted inside an L2 frame (e.g., EAPOL).
The W-AGF creates a registration request on behalf of the N5GC device with an indication that the registration is on behalf of an N5GC device. The SUPI of the N5GC device is the NAI as received from the device, and the W-AGF constructs the SUCI from this SUPI using the NULL scheme.
The W-AGF sends to the AMF/SEAF a registration request on behalf of the N5GC device. The registration request includes the NAI SUCI, wireline network name if available, and a device capability indicator (e.g., the device is non-5G capable).
The AMF/SEAF selects the AUSF based on the SUCI in the received registration request and sends a Nausf_UEAuthentication_Authenticate Request message to the AUSF. It contains the SUCI of the N5GC device, and an indicator that the request is on behalf of the N5GC device.
The AUSF starts EAP-TLS by sending to the AMF/SEAF a Nausf_UEAuthentication_Authenticate Response message containing an EAP-Request message of EAP-type=EAP-TLS with the Start (S) bit set, denoted as EAP-Request/EAP-TLS [TLS start].
After receiving the EAP-Request/EAP-TLS [TLS start] message from AMF/SEAF, the W-AGF forwards the EAP-Request/EAP-TLS [TLS start] message to the N5GC device in an L2 message, leaving out the ABBA and ngKSI parameters.
After receiving the EAP-Request/EAP-TLS [TLS start] message from the W-AGF, the N5GC device replies to the W-AGF with an EAP-Response/EAP-TLS message whose data field encapsulates a TLS client_hello message. Such EAP-Response message, denoted as EAP-Response/EAP-TLS [client_hello], is encapsulated in an L2 message.
The AUSF replies to the AMF/SEAF with EAP-Request/EAP-TLS message whose data field encapsulates a TLS server_hello message, a TLS server certificate message, a TLS server_key_exchange message, a TLS client certificate_request message, and a TLS server_hello_done message. Such EAP-Request message, denoted as EAP-Request/EAP-TLS [server_hello], is encapsulated in a Nausf_UEAuthentication_Authenticate Response message.
The N5GC device authenticates the AUSF by validating the server certificate included in the EAP-Request/EAP-TLS [server_hello] message received in step 8c. The N5GC device needs to be provisioned with certificates of a trust anchor to validate the AUSF server certificate. In addition, the N5GC device also needs to be provisioned with its own client certificate.
If the TLS server authentication is successful, then the N5GC device replies to the W-AGF with EAP-Response/EAP-TLS in an L2 message. The data field of the EAP-Response/EAP-TLS message contains a TLS client certificate message, a TLS client_key_exchange message, a TLS certificate_verify message, a TLS change_cipher_spec message, and TLS finished message. This EAP-Response message is denoted as EAP-Response/EAP-TLS [client_certificate].
The AUSF authenticates the N5GC device by verifying the client certificate received in the EAP-Response/EAP-TLS [client_certificate] message. Among other validations, the AUSF verifies that the client certificate is issued by a certificate authority trusted by the AUSF. If the client certificate is verified successfully, the AUSF continues to step 12a. Otherwise the AUSF returns an EAP-failure message. The AUSF needs to be provisioned with certificates of trust anchor to verify client certificates.
The AUSF sends to the AMF/SEAF an EAP-Request/EAP-TLS message with its data field encapsulating a TLS change_cipher_spec message and a TLS server finished. This EAP-Request message, denoted as EAP-Request/EAP-TLS [server_finished], is encapsulated in a Nausf_UEAuthentication_Authenticate Response message.
The AUSF sends to the AMF/SEAF an EAP-Success message along with the SUPI in a Nausf_UEAuthentication_Authenticate Response message. AUSF does not perform the derivation of K AUSF nor K SEAF based on the indicator of an N5GC device received in step 4c, nor sends K SEAF to AMF/SEAF.
It is recommended that the UE and DNS server(s) support DNS over (D)TLS as specified in RFC 7858  and RFC 8310 . The DNS server(s) that are deployed within the 3GPP network can enforce the use of DNS over (D)TLS. The UE can be pre-configured with the DNS server security information (out-of-band configurations specified in the IETF RFCs like, credentials to authenticate the DNS server, supported security mechanisms, port number, etc.), or the core network can configure the DNS server security information to the UE.
When DNS over (D)TLS is used, a TLS cipher suite that supports integrity protection needs to be negotiated.
ICMP (Internet Control Message Protocol) is part of the internet protocol (IP) suite. The lack of security in ICMP may be exploited to launch further attacks on the 3GPP system. To mitigate such attacks, it is recommended that the use of ICMP is restricted in the UE and the UPF (e.g., by default, use of ICMP is not allowed). In scenarios where the use of ICMP is required, it is recommended that one or more of following mitigations be enforced:
Disable the UE from responding to ICMP requests received over 3GPP network interface(s).
Install IP filter(s) at the UPF in order to block ICMP messages. This filter can be activated either on a per N4 Session basis or on a UPF basis. For ICMPv6, the recommendations in RFC 4890 can be used for filtering ICMPv6 messages.
Limit the maximum size of ICMP messages (e.g., to 64 bytes). Any ICMP messages that are greater than this limit needs to be dropped by the UE as well as by the UPF.