Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.501  Word version:  16.3.0

Top   Top   Up   Prev   None
1…   4…   5…   6…   6.2…   6.3…   6.5…   6.8…   6.9…   6.10…   6.12…   6.14   6.15   6.16   7…   7A…   7B…   8…   9…   10…   11…   13…   13.3…   13.4…   14…   15…   A…   B…   C…   D…   G…   K…   O…

 

O  Authentication for non-5G capable devices behind residential gateways |R16|Word‑p. 237

O.1  General

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.

O.2  Baseline for using non-5G capable devices with 5GC

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:
  1. the W-AGF creates the registration request on behalf of the N5GC device,
  2. 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
  3. Neither the N5GC device nor the AUSF derive any 5G related keys after EAP authentication.
Up

O.3  Authentication procedure

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
Up
In the following, the procedure for registration and authentication of an N5GC device to the 5GC is described:
Step 1.
The N5GC device connects to the W-AGF via a RG which is configured as a layer 2 bridge. The W-AGF is associated with a 5GC and acts on behalf of the N5GC device during its registration process.
Step 2a.
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).
Step 2b.
In response, the N5GC device sends back an EAP response/Identity including its Network Access Identifier (NAI) in the form of username@realm.
Step 3.
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.
Step 4a.
The W-AGF selects the AMF/SEAF.
Step 4b.
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).
Step 4c.
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.
Step 5a.
The AUSF sends a Nudm_UEAuthentication_Get Request to the UDM. It contains the SUCI of the N5GC device.
Step 5b.
The UDM invokes the SIDF to map the SUCI to the SUPI and selects an authentication method, e.g., EAP-TLS, based on the SUPI.
Step 5c.
The UDM sends a Nudm_UEAuthentication_Get Response to the AUSF, which contains the SUPI of the N5GC device and an indicator of the selected authentication method, e.g., EAP-TLS.
Step 6a.
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].
Step 6b.
The AMF/SEAF forwards the EAP-Request/EAP-TLS [TLS start] in the Authentication Request message to the W-AGF.
Step 6c.
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.
Step 7a.
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.
Step 7b.
The W-AGF forwards the EAP-Response/EAP-TLS [client_hello] to the AMF/SEAF in an Authentication Response message.
Step 7c.
The AMF/SEAF forwards the EAP-Response/EAP-TLS [client_hello] message to the AUSF in a Nausf_UEAuthentication_Authenticate Request message.
Step 8a.
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.
Step 8b.
The AMF/SEAF forwards the EAP-Request/EAP-TLS [server_hello] message to the W-AGF in an Authentication Request message.
Step 8c.
The W-AGF forwards the EAP-Request/EAP-TLS [server_hello] to the N5GC device in an L2 message.
Step 9.
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.
Step 10a.
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].
Step 10b.
The W-AGF forwards to the AMF/SEAF the EAP-Response/EAP-TLS [client_certificate] in an Authentication Response message.
Step 10c.
The AMF/SEAF forwards the EAP-Response/EAP-TLS [client_certificate] message to the AUSF in a Nausf_UEAuthentication_Authenticate Request message.
Step 11.
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.
Step 12a.
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.
Step 12b.
The AMF/SEAF forwards EAP-Request/EAP-TLS [server_finished] message to the W-AGF in an Authentication Request message.
Step 12c.
The W-AGF forwards EAP-Request/EAP-TLS [server_finished] message to the N5GC device in an L2 message.
Step 13a.
The N5GC sends to the W-AGF an EAP-Response/EAP-TLS message with its data field set to empty, denoted as EAP-Response/EAP-TLS [empty], in an L2 message
Step 13b.
The W-AGF forwards to the AMF/SEAF the EAP-Response/EAP-TLS [empty] message in an Authentication Response message.
Step 13c.
The AMF/SEAF forwards the EAP-Response/EAP-TLS [empty] message to the AUSF in a Nausf_UEAuthentication_Authenticate Request message.
Step 14a.
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.
Step 14b.
The AMF/SEAF forwards to the W-AGF the EAP-Success message in an Authentication Result message or a Security Mode Command message.
Step 14c.
The W-AGF forwards to the N5GC device the EAP-Success message in an L2 message, and the authentication procedure is finished.
Step 15.
The AMF sends Registration Accept message to the W-AGF.
Up

P  Security Aspects of DNS and ICMP |R16|Word‑p. 241

P.1  General

This annex specifies security measures to protect DNS and ICMP messages. These security measures are intended when integrity protection over the user plane can not be used.

P.2  Security aspects of DNS

It is recommended that the UE and DNS server(s) support DNS over (D)TLS as specified in RFC 7858 [83] and RFC 8310 [84]. 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.
Up

P.3  Security aspects of ICMP

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.
Up

Q  Security and privacy in 5G system location services |R16|

Q.1  General

For security and privacy in 5GS LCS (5G System Location Services), the mechanisms defined in TS 23.273 and TS 38.305 apply.

$  Change historyWord‑p. 242

Up   Top