Content for TS 33.536 Word version: 17.1.0

1… 5… 5.3.3.1.4 5.3.3.1.5 5.3.3.2… 5.4…

5.3.3.1.4 Security establishment procedures
...

5.3.3.1.4 Security establishment procedures p. 12

5.3.3.1.4.1 General p. 12

Clause 5.3.3.1.4.2 describes the security policy and how the UEs handle the policy. There are two different cases when an overall security context may be established; to set up a new connection and to re-key an ongoing connection. These cases are described in clauses 5.3.3.1.4.3 and 5.3.3.1.4.4 respectively. Clause 5.3.3.1.4.5 describes the establishment of security for a user plane bearer.

5.3.3.1.4.2 Security policy p. 12

5.3.3.1.4.2.1 General p. 12

The PC5 unicast link shall support activation or deactivation of security based on the security policy similar to Uu, as defined in TS 33.501. The security policy shall be provisioned for PC5 unicast link as well, as detailed in clause 5.3.3.1.4.2.2 of the present document and handled as detailed in clause 5.3.3.1.4.2.3 of the present document.

5.3.3.1.4.2.2 Procedure for security policy provisioning for PC5 unicast link p. 12

For selectively activating or deactivation the security of the PC5 unicast link, the PCF may provision the security policy per V2X service, during service authorization and information provisioning procedure as defined in TS 23.287.

5.3.3.1.4.2.3 Security policy handling p. 12

For a NR PC5 unicast link, the UE shall be provisioned with the following:

The list of V2X services, e.g. PSIDs or ITS-AIDs of the V2X applications, with Geographical Area(s) and their security policy which indicates the following:
- Signalling integrity protection: REQUIRED/PREFERRED/NOT NEEDED
- Signalling confidentiality protection: REQUIRED/PREFERRED/NOT NEEDED
- User plane integrity protection: REQUIRED/PREFERRED/NOT NEEDED
- User plane confidentiality protection: REQUIRED/PREFERRED/NOT NEEDED

REQUIRED means the UE shall only accept the connection if a non-NULL confidentiality or integrity algorithm is used for protection of the traffic.

NOT NEEDED means that the UE shall only establish a connection with no security.

PREFFERED means that the UE may try to establish security but may will accept the connection with no security. One use of PREFERRED is to enable a security policy to be changed without updating all UEs at once.

The handling of signalling security policy proceeds as follows:

At initial connection, the initiating UE includes its signalling security policy in the Direct Communication Request message. The receiving UE(s) takes this into account when deciding whether to accept or reject the request and when deciding the agreed security policy to be sent back in the Direct Security Mode Command message. The initiating UE can reject the Direct Security Mode Command if the algorithm choice does not match its policy (see clause 5.3.3.1.4.3 for full details of the handling).

All the UP data of PC5 unicast link shall have the same security.

The handling of the user plane security policy proceeds with the following sequence:

At initial connection, the UE that sent the Direct Communications Request shall include the user plane security policy for the service in the Direct Security Mode Complete message.
If the signalling confidentiality protection is not activated, then UEs shall treat their user plane confidentiality policy for the V2X service for this connection as NOT NEEDED and the receiving UE shall set confidentiality for the user plane to off. The receiving UE may accept the Direct Communication Request and the response message (i.e. Direct Communication Accept) shall include the configuration of not activating (i.e. set to off) the user plane confidentiality protection.
The receiving UE shall reject the Direct Communication Request when the following cases occur: 1) if the received user plane security policy had either confidentiality/integrity set to NOT NEEDED and its own corresponding policy is set to REQUIRED or, 2) if the received user plane security policy had either confidentiality/integrity set to REQUIRED and its own corresponding policy is set to NOT NEEDED.
Otherwise, the receiving UE may accept the Direct Communication Request and the response message (i.e. Direct Communication Accept) shall include the configuration of user plane confidentiality protection based on the agreed user plane security policy, set as follows:
1. User plane confidentiality protection set to off if the received user plane security policy had either confidentiality set to NOT NEEDED and/or its own user plane security policy for the service is set to NOT NEEDED; or
2. User plane confidentiality protection set to on if the received user plane security policy had either confidentiality set to REQUIRED and/or its own user plane security policy for the service its own corresponding policy is set to REQUIRED; or
3. User plane confidentiality protection set to off or on otherwise (i.e. when both the received user plane security policy and its own user plane security policy for the service had the confidentiality set to PREFERRED).

User plane integrity protection set following the same rules as confidentiality protection but based on the received and its own user plane integrity protection policy for the service.

Due to the purpose of adding a new V2X service to an existing PC5 unicast link, if the signalling and user plane security policies of the new V2X service are satisfied by the security in use for the PC5 unicast link, the initiating UE shall send the Link Modification Request to the receiving UE. The receiving UE shall reject the Link Modification Request if the security in use for the PC5 unicast link does not match the signalling and user plane security policies of the new V2X service.

The V2X layer of the UE shall pass the security configurations to its AS layer. The security configurations are mutually agreed by both sides' UEs, including the configuration of confidentiality and integrity protection.

5.3.3.1.4.3 Security policy p. 13

The clause describes how security is established during connection set-up. The signalling flow is shown in Figure 5.3.3.1.4.3-1.

Copy of original 3GPP image for 3GPP TS 33.536, Fig. 5.3.3.1.4.3-1: Security establishment at connection set-up

Figure 5.3.3.1.4.3-1: Security establishment at connection set-up
(⇒ copy of original 3GPP image)

Step 1.

UE_1 has sent a Direct Communication Request to UE_2. This message shall include UE_1's security capabilities (the list of algorithms that UE_1 will accept for this connection) and UE_1's signalling security policy. The UE_1 shall also include Nonce_1 (for session key KNRP-sess generation), and the most significant 8-bits of the KNRP-sess ID in this message if UE_1's signalling integrity protection policy is either "REQUIRED" or "PREFERRED". The most significant 8-bits of the KNRP-sess ID shall be chosen such that UE_1 will be able to locally identify a security context that is created by this procedure using the KNRP-sess ID. The message may also include a KNRP ID if the UE_1 has an existing KNRP for the UE that it is trying to communicate with. The absence of the KNRP ID parameter indicates that UE_1 does not have a KNRP for UE_2. The message also contains Key_Est_Info (see clause 5.3.3.1.3.2).

Step 2.

UE_2 shall reject the Direct Communication Request if UE_1's signalling security policy is "NOT NEEDED" while UE_2's security policy is "REQUIRED". UE_2 shall also reject the Direct Communication Request if UE_1's signalling security policy is "REQUIRED" while UE_2's security policy is "NOT NEEDED". UE_2 may initiate a Direct Authentication and Key Establishment procedure with UE_1. This is mandatory if the UE_2 does not have the KNRP and KNRP ID pair indicated in step 1, and signalling is needed to establish the keys for the particular use case. If the Direct Authentication and Key Establishment procedure is initiated, the two UEs authenticate each other using the information exchanged in Key_Est_Info, where the used authentication method is application-specific. (See clause 5.3.3.1.3.2). During Direct Authentication and Key Establishment procedure, either of the UE's may reject the authentication procedure.

Step 3.

UE_2 shall send the Direct Security Mode Command message to UE_1. This message shall only contain the MSB of KNRP ID unless the Null integrity algorithm is selected by UE_2 and optionally Key_Est_Info if a fresh KNRP is to be generated (see clause 5.3.3.1.3). UE_2 shall include the Chosen_algs parameter to include the selected integrity and confidentiality algorithm. Non-Null security algorithm in the Chosen_algs indicates the corresponding security protection is activated and the security algorithm the UEs will use to protect the data in the message. Null security algorithm in the Chosen_algs indicates the corresponding security protection is unprotected. The Chosen_algs may only indicate the use of the NULL integrity algorithm if UE_2's signalling integrity security policy is either NOT NEEDED or PREFERRED. UE_2 shall also return the UE_1's security capabilities and UE_1's signalling security policy to provide protection against bidding down attacks. In the case that the NULL integrity algorithm is chosen, the NULL confidentiality algorithm shall also be chosen and UE_2 shall set the KNRP-sess ID of this security context to the all zero value.

The following procedures in step 3 shall only be executed if the UE_2 decides to at least activate the integrity security protection for this connection: UE_2 shall also include Nonce_2 to allow a session key to be calculated, as well as the least significant 8-bits of KNRP-sess ID in the messages. These bits are chosen so that UE_2 will be able to locally identify a security context that is created by this procedure. UE_2 shall calculate KNRP-Sess from KNRP and both Nonce_1 and Nonce_2 (see clause A.3) and then derive the confidentiality (if applicable) and integrity keys based on the chosen algorithms (clause A.2). The lower layer shall be provided with the new security context and indication(s) to signal that the Direct Security Mode Command message needs integrity protection with the new security context and the signalling messages can be received using the new security context. The confidentiality key, NRPEK, shall be derived in this step if and only if signalling confidentiality protection is activated for this connection. The integrity protection key, NRPIK, shall be derived in this step if and only if signalling integrity protection is activated for this connection. UE_2 shall integrity protect the Direct Security Mode Command before sending it to UE_1. UE_2 is then ready to receive signalling and messages protected with the new security context. UE_2 shall form the KNRP-sess ID from the most significant bits it received in step1 and least significant bits it sent in step3.

Step 4.

On receiving the Direct Security Mode Command, the UE_1 shall first check the Chosen_algs and shall accept the NULL integrity algorithm only if its security policy for signalling integrity protection is either NOT NEEDED or PREFERRED. Then UE_1 shall check the returned UE_1's security capabilities and UE_1's signalling security to avoid bidding down attacks if the NULL integrity algorithm is selected for signalling integrity protection. If the above check passes, UE_1 shall send an unprotected Direct Security Mode Complete message to UE_2. UE_1 shall set the KNRP-sess ID of this security context to the all zero value.

Under the condition of non-NULL integrity algorithm indicated in the Chosen_algs, UE_1 shall first check that the received LSB of KNRP-sess ID is unique by checking that it has not been sent by another UE responding to this Direct Communication Request i.e. such that resulting KNRP-sess ID is not already being used for another link. If the LSB of KNRP-sess ID is not unique, then UE_1 shall respond with a Direct Security Mode Reject message including a cause value to specify that the LSB of KNRP-sess ID is not unique. The peer UE-2 receiving a Direct Security Mode Reject message shall inspect the cause value and, if the cause is related to the session identifier uniqueness then, the UE-2 shall generate a new LSB of KNRP-sess ID and reply to UE-1 again (i.e., UE-2 shall send a Direct Security Mode Command message with the new LSB of KNRP-sess ID). UE_2 shall associate the new LSB of KNRP-sess ID with the security context that is created in step 3. UE-2 shall erase the former LSB of KNRP-sess ID from its memory. On receiving this new Direct Security Mode Command, UE_1 shall process the message from the start of step 4.

If the LSB of KNRP-sess ID is unique, UE_1 shall calculate KNRP-sess and the confidentiality key (if applicable) and integrity key in the same way as UE_2. The confidentiality key, NRPEK, shall be derived in this step if and only if the Chosen_algs includes non-NULL confidentiality algorithm. The integrity protection key, NRPIK, shall be derived in this step if and only if signalling integrity protection is activated for this connection. UE_1 shall check that the returned UE_1 security capabilities and UE_1's signalling security policy are the same as those it sent in step 1. UE_1 shall also check the integrity protection on the message. If both these checks pass, then UE_1 creates a security context to be associated with the KNRP-sess ID. UE_1 is ready to send and receive signalling and message with the new security context. The lower layer shall be provided with the new security context and indication to signal that signalling starting with the Direct Security Mode Complete needs protection with new security context and the signalling messages can be received using the new security context. UE_1 shall send integrity protected and confidentiality protected (if applicable) Direct Security Mode Complete message to UE_2. UE_1 shall form the KNRP-sess ID from the most significant bits it sent in step1 and least significant bits it received in step3. KNRP-sess ID is used to locally identify the security context that is created by this procedure.

Step 5.

If the Chosen_algs in step 3 includes non-NULL integrity algorithm, UE_2 checks the integrity protection on the received Direct Security Mode Complete. If this passes, UE_2 is now ready to send signalling message and send and receive user plane traffic protected with the new security context. UE_2 shall send integrity protected and confidentiality (if applicable) protected Direct Communication Accept message to UE_1 with the new security context. The lower layer shall be provided with an indication before sending Direct Communication Accept message to indicate that the signalling message starting with the Direct Communication Accept is protected with the new security context and an indication after sending Direct Communication Accept message to indicate that the user plane traffic is protected with the new security context. UE_2 deletes any old security context it has for UE_1.

Step 6.

After receiving the Direct Communication Accept message, the lower layer of UE_1 shall be provided with an indication of activation of the PC5 unicast user plane security protection for the PC5 unicast link (if applicable). UE_1 is now ready to send and receive user plane traffic protected with the new security context. UE_1 deletes any old security context it has for UE_2.

5.3.3.1.4.4 Security establishment during re-keying p. 15

By rekeying, the UEs ensure fresh session keys KNRP-sess are used. Optionally the rekeying can also enforce refresh of KNRP. Either UE may rekey the connection at any time. This shall be done before the counter for a PDCP bearer repeats with the current keys. A rekeying operation shall refresh the KNRP-sess and NRPEK and NRPIK, and may refresh KNRP. There is no benefit in running the rekeying procedure if the NULL integrity algorithm is in use, hence it is recommended not to trigger it when using the NULL integrity algorithm. A rekeying operation follows the flows given in Figure 5.3.3.1.4.4-1.

Copy of original 3GPP image for 3GPP TS 33.536, Fig. 5.3.3.1.4.4-1: Security establishment during rekeying

Figure 5.3.3.1.4.4-1: Security establishment during rekeying
(⇒ copy of original 3GPP image)

Step 1.

UE_1 sends a Direct Rekey Request to UE_2. This message shall include UE_1 security capabilities (the list of algorithms that UE_1 will accept for this connection). In addition, if a non-Null integrity algorithm is in use, the message shall include Nonce_1 (for session key generation) and the most significant 8-bits of the KNRP-sess ID. These bits are chosen such that UE_1 will be able to locally identify a security context that is created by this procedure. The message may also include a Re-auth Flag if UE_1 wants to rekey KNRP. The message also contains Key_Est_Info (see clause 5.3.3.1.3.2).

Step 2.

UE_2 may initiate a Direct Auth Key Establish procedure with UE_1. This is mandatory if UE_1 included the Re-auth Flag and signalling is needed to establish KNRP.

Step 3.

This step is the same as step 3 in clause 5.3.3.1.4.3 except the following differences: the chosen integrity algorithm shall only be NULL if and only if the NULL integrity algorithm is currently in use, the chosen confidentiality algorithm shall only be NULL if and only if the NULL confidentiality algorithm is currently in use and UE_1's signalling security policy is not included in this message. UE_2 is then ready to receive both signalling and user plane traffic protected with the new security context. The lower layer shall be provided with an indication that the new security context can be used to receive protected user plane traffic in addition to the indication(s) from step 3 in clause 5.3.3.1.4.3.

Step 4.

This step is the same as step 4 in clause 5.3.3.1.4.3 except the following differences:the UE_1 shall only accept the NULL integrity algorithm if and only if the NULL integrity algorithm is currently in use, UE_1 shall only accept the NULL confidentiality algorithm if and only if the NULL confidentiality algorithm is currently in use, and UE_1 does not check the returned signalling security policy (as it is not sent in this case). UE_2 is then ready to both send and receive both signalling and user plane traffic protected with the new security context. The lower layer shall receive an indication that the new security context shall be used to send and can be used to receive protected user plane traffic after the Direct Security Mode Complete message has been sent in addition to the indications given in step 4.

Step 5.

This step is the same as step 5 in clause 5.3.3.1.4.3 except the following changes: the Direct Communication Accept message is replaced by Direct Link Rekeying Response message. There is no need for the indication to be ready to receive user plane with the new context as this indication was received at step 3 but the rest of the indication from step 5 of clause 5.3.3.1.4.3 are needed.

Step 6.

This step is the same as step 6 in clause 5.3.3.1.4.3 except the following: the Direct Communication Accept message is replaced by Direct Link Rekeying Response message. No indication to the AS layer is needed at this step.

5.3.3.1.4.5 Security establishment for user plane bearers p. 16

The UEs handle the user plane security policies as described in clauses 5.3.3.1.4.2.3.

The UE initiating the establishment of a user plane bearer shall select an LCID whose associated value of Bearer for input to the security algorithms (see clauses 5.3.3.1.5.2 and 5.3.3.1.5.3) has not been used with the current keys, NRPEK and NRPIK. If this is not possible the UE shall initiate a re-keying (see clause 5.3.3.1.4.4) before establishing the user plane bearer.

When establishing or re-configuring the user plane bearers, the UEs shall activate the user plane security for the bearers according to the configuration of confidentiality and integrity protection received from its V2X layer. The confidentiality and/or integrity protection algorithms are same as those selected for protecting the signalling bearers if confidentiality and/or integrity protection are required for both signalling and user plane. The user plane confidentiality protection algorithm is the same as the selected signalling confidentiality algorithm if signalling confidentiality protection is not activated.

Both UEs shall ensure that the user plane for each V2X service is only sent or received (e.g. dropped if received on a bearer with incorrect security) on user plane bearers with the necessary security if security protection of this link is activated.