Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.503  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4…   5…   6…   6.1.3.2…   6.1.3.2.2.2…   6.2…   6.3…   6.3.3.2…   6.3.3.3…   6.3.4…   6.4…   7…   A…

 

6  Security for 5G ProSe featuresp. 14

6.1  Security for 5G ProSe Discoveryp. 14

6.1.1  Generalp. 14

6.1.2  Security requirementsp. 14

The 5G System shall support integrity protection and replay protection of discovery messages in open 5G ProSe Direct Discovery.
The 5G System shall support confidentiality protection, integrity protection and replay protection of discovery messages in restricted 5G ProSe Direct Discovery.
The 5G System shall support a method to verify source authenticity of discovery messages.

6.1.3  Security proceduresp. 14

6.1.3.1  Open 5G ProSe Direct Discoveryp. 14

The open 5G ProSe Direct Discovery security procedure is described as follows.
Copy of original 3GPP image for 3GPP TS 33.503, Fig. 6.1.3.1-1: Open 5G ProSe Direct Discovery security procedure
Up
Step 1.
The Announcing UE sends a Discovery Request message containing the ProSe Application ID to the 5G DDNMF in its HPLMN in order to be allowed to announce a code on its serving PLMN (either VPLMN or HPLMN).
Step 2.
If the Announcing UE wants to send announcements in the VPLMN, it needs to be authorized from the VPLMN 5G DDNMF. The 5G DDNMF in the HPLMN requests authorization from the VPLMN 5G DDNMF by sending Announce Auth.() message.
Step 3.
VPLMN 5G DDNMF responds with an Announce Auth. Ack () message, if authorization is granted. There are no changes to these messages for the purpose of protecting the transmitted code for open 5G ProSe Direct Discovery. If the Announcing UE is not roaming, these steps do not take place.
Step 4.
The 5G DDNMF in HPLMN of the Announcing UE returns the ProSe Application Code that the Announcing UE can announce and a Discovery Key associated with it. The 5G DDNMF stores the Discovery Key with the ProSe Application Code. In addition, the 5G DDNMF provides the UE with a CURRENT_TIME parameter, which contains the current UTC-based time at the 5G DDNMF, a MAX_OFFSET parameter, and a Validity Timer. The UE sets a clock which is used for ProSe authentication (i.e. ProSe clock) to the value of CURRENT_TIME and the UE stores the MAX_OFFSET parameter, overwriting any previous values. The Announcing UE obtains a value for a UTC-based counter associated with a discovery slot based on UTC time. The counter is set to a value of UTC time in a granularity of seconds. The UE may obtain UTC time from any sources available, e.g. the RAN via SIB9, NITZ, NTP, GPS, via Ub interface (in GBA) (depending on which is available).
Step 5.
The UE starts announcing, if the difference between UTC-based counter provided by the system associated with the discovery slot and the UE's ProSe clock is not greater than the MAX_OFFSET and if the Validity Timer has not expired. For each discovery slot it uses to announce, the Announcing UE calculates a 32-bit Message Integrity Check (MIC) to include with the ProSe Application Code in the discovery message. Four least significant bits of UTC-based counter are transmitted along with the discovery message. The MIC is calculated as described in clause A.6 using the Discovery Key and the UTC-based counter associated with the discovery slot.
Step 6.
The Monitoring UE sends a Discovery Request message containing the ProSe Application ID to the 5G DDNMF in its HPLMN in order to get the Discovery Filters that it wants to listen for.
Step 7.
The 5G DDNMF in the HPLMN of the Monitoring UE sends Monitor Req. message to the 5G DDNMF in the HPLMN of the Announcing UE.
Step 8.
The 5G DDNMF in the HPLMN of the Announcing UE sends Monitor Resp. message to the 5G DDNMF in the HPLMN of the Monitoring UE.
Step 9.
The 5G DDNMF returns the Discovery Filter containing either the ProSe Application Code(s), the ProSe Application Mask(s) or both along with the CURRENT_TIME and the MAX_OFFSET parameters. The Monitoring UE sets its ProSe clock to CURRENT_TIME and stores the MAX_OFFSET parameter, overwriting any previous values. The Monitoring UE obtains a value for a UTC-based counter associated with a discovery slot based on UTC time. The counter is set to a value of UTC time in a granularity of seconds. The Monitoring UE may obtain UTC time from any sources available, e.g. the RAN via SIB9, NITZ, NTP, GPS (depending on which is available).
Step 10.
The Monitoring UE listens for a discovery message that satisfies its Discovery Filter, if the difference between UTC-based counter associated with that discovery slot and UE's ProSe clock is not greater than the MAX_OFFSET of the Monitoring UE's ProSe clock.
Step 11.
On hearing such a discovery message, and if the UE has either not checked the MIC for the discovered ProSe App Code via Match Report previously or has checked a MIC for the ProSe App Code via Match Report and the associated Match Report refresh timer (see steps 14 and 15 for details of this timer) has expired, or as required based on the procedure specified in TS 23.304, the Monitoring UE sends a Match Report message to the 5G DDNMF in the HPLMN of the Monitoring UE. The Match Report contains the UTC-based counter value with four least significant bits equal to four least significant bits received along with discovery message and nearest to the Monitoring UE's UTC-based counter associated with the discovery slot where it heard the announcement, and other discovery message parameters including the ProSe App Code and MIC. If a Match Report is not required, the Monitoring UE shall locally process the discovery message and the rest of the procedure is not performed.
Step 12.
The 5G DDNMF in the HPLMN of the Monitoring UE passes the discovery message parameters including the ProSe Application Code and MIC and associated counter parameter to the 5G DDNMF in the HPLMN of the Announcing UE in the Match Report message.
Step 13.
The 5G DDNMF in the HPLMN of the Announcing UE shall check the MIC is valid. The relevant Discovery Key is identified by the ProSe Application Code.
Step 14.
The 5G DDNMF in the HPLMN of the Announcing UE shall acknowledge a successful check of the MIC to the 5G DDNMF in the HPLMN of the Monitoring UE via the Match Report Ack message. The 5G DDNMF in the HPLMN of the Announcing UE include a Match Report refresh timer in the Match Report Ack message. The Match Report refresh timer indicates how long the UE will wait before sending a new Match Report for the ProSe Application Code.
Step 15.
The 5G DDNMF in the HPLMN of the Monitoring UE acknowledges the MIC check result to the Monitoring UE. The 5G DDNMF returns the parameter ProSe Application ID to the UE. It also provides the CURRENT_TIME parameter, by which the UE (re)sets its ProSe clock. The 5G DDNMF in the HPLMN of the Monitoring UE may optionally modify the received Match Report refresh timer based on local policy and then include the Match Report refresh timer in the message to the Monitoring UE.
Up

Up   Top   ToC