Content for  TS 33.401  Word version:  17.3.0

Key-change-on-the fly consists of re-keying or key-refresh. Key refresh shall be possible for KeNB, KRRC-enc, KRRC-int, KUP-int, and KUP-enc and shall be initiated by the eNB when a PDCP COUNTs is about to be re-used with the same Radio Bearer identity and with the same KeNB. The procedure is described in clause 7.2.9.3. Re-keying shall be possible for the KeNB, KRRC-enc, KRRC-int, KUP-int, and KUP-enc. This re-keying shall be initiated by the MME when an EPS AS security context different from the currently active one shall be activated. The procedures for doing this are described in clause 7.2.9.2. Re-keying shall be possible for KNAS-enc and KNAS-int. Re-keying of KNAS-enc and KNAS-int shall be initiated by the MME when a EPS NAS security context different from the currently active one shall be activated. The procedures for doing this are described in clause 7.2.9.4. Re-keying of the entire EPS key hierarchy including KASME shall be achieved by first re-keying KASME, then KNAS-enc and KNAS-int, followed by re-keying of the KeNB and derived keys. For NAS key change-on-on-the fly, activation of NAS keys is accomplished by a NAS SMC procedure. AS Key change on-the-fly is accomplished using a procedure based on intra-cell handover. The following AS key changes on-the-fly shall be possible: local KeNB refresh (performed when PDCP COUNTs are about to wrap around), KeNB re-keying performed after an AKA run, activation of a native context after handover from UTRAN or GERAN.

The KeNB re-keying procedure is initiated by the MME. It may be used under the following conditions:

• after a successful AKA run with the UE as part of activating a partial native EPS security context, or
• as part of re-activating a non-current full native EPS security context after handover from GERAN or UTRAN according to clauses 9.2.2.1 and 10.3.2, or
• to create a new KeNB from the current KASME

In order to be able to re-key the KeNB, the MME requires a fresh uplink NAS COUNT from a successful NAS SMC procedure with the UE. In the case of creating a new KeNB from the current KASME a NAS SMC procedure shall be run first to provide this fresh uplink NAS COUNT. This NAS SMC procedure does not have to change other parameters in the current EPS NAS security context. T he MME derives the new KeNB using the key derivation function as specified in Annex A.3 using the KASME and the uplink NAS COUNT used in the most recent NAS Security Mode Complete message. The KeNB is sent to the eNB in an S1 AP UE CONTEXT MODIFICATION REQUEST message triggering the eNB to perform the re-keying. The eNB runs the key-change-on-the-fly procedure with the UE. During this procedure the eNB shall indicate to the UE that a key change on-the-fly is taking place. The procedure used is based on an intra-cell handover, and hence the same KeNB derivation steps shall be taken as in a normal handover procedure. When the UE receives an indication that the procedure is a key change on-the-fly procedure, the UE shall derive a temporary KeNB by applying the key derivation function as specified in Annex A.3 using the KASME from the current EPS NAS security context and the uplink NAS COUNT in the most recent NAS Security Mode Complete message. From this temporary KeNB the UE shall derive the KeNB* as normal (see clause A.5). The eNB shall take the KeNB it received from the MME, which is equal to the temporary KeNB, as basis for its KeNB* derivations. From this step onwards, the key derivations continue as in a normal handover. If the AS level re-keying fails, then the MME shall complete another NAS security mode procedure before initiating a new AS level re-keying. This ensures that a fresh KeNB is used. The NH parameter shall be handled according to the following rules:

• UE and MME shall use NH derived from old KASME before the context modification is complete, i.e. for the UE when it sends the RRC Connection Reconfiguration Complete, and for the MME when it receives the UE CONTEXT MODIFICATION RESPONSE. In particular, the MME shall send an NH derived from old KASME in the S1AP HANDOVER RESOURCE ALLOCATION, S10 FORWARD RELOCATION, and S1AP PATH SWITCH REQUEST ACKNOWLEDGE messages before the context modification is complete.
• The eNB shall delete any old NH upon completion of the context modification.
• The UE and MME shall delete any old NH upon completion of the context modification. After the completion of the context modification, the UE and the MME shall derive any new NH parameters from the KeNB calculated from the uplink NAS COUNT and the KASME used to calculate that KeNB according to Annex A.4.

This procedure is based on an intra-cell handover. The KeNB chaining that is performed during a handover ensures that the KeNB is re-freshed w.r.t. the RRC and UP COUNT after the procedure.

After an AKA has taken place, new NAS keys from a new KASME shall be derived, according to Annex A.7. To re-activate a non-current full native EPS security context after handover from GERAN or UTRAN, cf. clause 9.2.2 B step 7, the UE and the MME take the NAS keys into use by running a NAS SMC procedure according to clause 7.2.4.5. MME shall activate fresh NAS keys from an EPS AKA run or activate native security context with sufficiently low NAS COUNT values before the NAS uplink or downlink COUNT wraps around with the current security context.

The purpose of this procedure is to allow the eNB to suspend an RRC connection to be resumed by the UE at a later time. The UE may resume the RRC connection in the same or different eNB than where the suspend took place. The UE and eNB store the AS security context at suspend and reactivate the AS security context at resume. The UE and the eNB may also use EDT (Early Data Transmission) feature in this procedure, as defined in TS 36.331.

When the eNB initiates the RRC Connection Suspend procedure it sends S1-AP UE Context Suspend Request message to the MME. Upon reception of the S1-AP UE Context Suspend Request message the MME shall check its local policy. If the local policy indicates that a new NH derivation is needed, the MME shall increase its locally kept NCC value by one and compute a fresh NH from its stored data using the function defined in Annex A.4. The MME shall store that fresh {NH, NCC} pair and send it to the eNB in the S1-AP UE Context Suspend Response message. Upon receipt of the S1-AP UE Context Suspend Response message from the MME and if the message includes a {NH, NCC} pair, the eNB shall store the fresh {NH, NCC} pair in the S1-AP UE Context Suspend Response message and remove any existing unused stored {NH, NCC} pairs. The eNB shall include a Resume ID, to be used for context identification and re-establishment, in the RRC Connection Suspend message sent from the eNB to the UE. The RRC Connection Suspend message is protected in PDCP layer using the current AS security context. The eNB shall store the Resume ID together with the UE context including the AS security context. The UE ID part of the Resume ID assigned by the eNB shall be different in consecutive suspends of the same UE. This is to avoid tracking of UEs based on the Resume ID. If the eNB has a fresh {NH, NCC} pair, the eNB shall keep KRRCint and delete other keys of the AS security context, i.e. keys KeNB, KRRCenc, KUPenc shall be deleted after sending the RRC Connection Suspend message to the UE. Otherwise, if a fresh {NH, NCC} pair was not received from the MME the eNB shall keep the AS keys. When the UE receives the RRC Connection Suspend message from the eNB, then the UE shall store the Resume ID together with the current UE context including the AS security context until the UE decides to resume the RRC connection. When the EDT feature is used, the subsequent handling shall apply to the RRC Connection Suspend procedure. If the eNB has a fresh and unused pair of {NH, NCC}, then the eNB shall include the fresh NCC in the RRC Connection Suspend message. The eNB shall keep the current KRRCint, but delete other current AS keys KeNB, KRRCenc, and KUPenc. Otherwise, if the eNB does not have a fresh and unused pair of {NH, NCC}, then the eNB shall include the same NCC value associated with the current KeNB in the RRC Connection Suspend message. In this case, the eNB shall keep the current KRRCint and the current KeNB, but delete other current AS keys KRRCenc, and KUPenc. When the UE receives the RRC Connection Suspend message including an NCC value, then the UE shall take the received NCC value for use in the next resume. NCC received in RRC Connection Suspend message shall only be used for initiating EDT resume.

When the UE decides to resume the RRC connection, the UE sends the RRC Connection Resume Request message on SRB0 and hence it is not integrity protected. The UE shall include information to be used for context identification and re-establishment in the RRC Connection Resume Request message: the Resume ID and a ShortResumeMAC-I. The ShortResumeMAC-I is a message authentication token, which shall be calculated with the following inputs: source C-RNTI, source PCI, resume constant and target Cell-ID as defined by VarShortResumeMAC-Input in TS 36.331 and using the stored KRRCint used with the source eNB where the UE was suspended. The Resume ID was assigned to the UE in the cell where the UE was suspended (the source cell). The source PCI and source C-RNTI are associated with the cell where the UE was suspended. The target Cell-ID is the identity of the target cell where the UE sends the RRC Connection Resume Request message. The resume constant allows differentiation of VarShortResumeMAC from VarShortMAC. The integrity algorithm shall be the negotiated EIA-algorithm from the stored AS security context from the source eNB.

• KEY shall be set to KRRCint of the source cell;
• all BEARER bits shall be set to 1;
• DIRECTION bit shall be set to 1;
• all COUNT bits shall be set to 1.

The ShortResumeMAC-I shall be the 16 least significant bits of the output of the used integrity algorithm. The target eNB extracts the Resume ID and ShortResumeMAC-I from the RRC Connection Resume Request. The target eNB contacts the source eNB based on the information in the Resume ID by sending a Retrieve UE Context Request message on X2 interface including the Resume ID, the ShortResumeMAC-I and Cell-ID of target cell, in order to retrieve the UE context including the AS security context. The source eNB retrieves the stored UE context including the AS security context from its database identified by the Resume ID and the source eNB calculates and verifies the ShortResumeMAC-I (calculating it in the same way as described above). If the check of the ShortResumeMAC-I is successful, then the source eNB shall derive a new KeNB* as described in Annex A.5 based on the target PCI and target EARFCN-DL. The source eNB can obtain the target PCI and target EARFCN-DL from a cell configuration database by means of the target Cell-ID. If the source eNB has a fresh {NH, NCC} pair from the MME then that pair shall be used and the fresh NH shall be used as in the new KeNB* derivation. The source eNB responds with a Retrieve UE Context Response message to the target eNB on X2 interface including the UE context including the AS security context. The AS security context sent to the target eNB shall include the new derived KeNB*, the NCC associated to the KeNB*, the UE EPS security capabilities including the security algorithms supported by the UE and ciphering and integrity algorithms used in the source cell. The target eNB shall check if it supports the ciphering and integrity algorithms used in the source cell. If this is not the case, the target eNB shall send an appropriate error message to the UE. If the check is successful the target eNB derives new AS keys (RRC integrity key, RRC encryption key and UP keys) corresponding to the algorithms from the received KeNB*, reset all PDCP COUNTs to 0 and activates the new keys in PDCP layer. The target eNB responds with a RRC Connection Resume message including the NCC received from source eNB to the UE on SRB1, integrity protected in PDCP layer using the new AS keys. The RRC Connection Resume message may include RRC connection reconfiguration parameters as defined in TS 36.300. When the UE receives the RRC Connection Resume message, then the UE shall check if the received NCC value is different from the current NCC value stored in the UE itself. If the NCC values differ then the UE needs to synchronize its locally kept NH as defined in Annex A.4. The UE then calculates a new KeNB* from either the new NH (if a new NCC value was received) or the current KeNB*, using the target cell's PCI and its frequency EARFCN-DL in the target cell. The UE performs then further derivation of the AS keys (RRC integrity key, RRC encryption key and UP keys) from the new derived KeNB*. The UE checks the integrity of the RRC Connection Resume message by verifying the MAC-I. If the verification of the MAC-I is successful, then the UE resets all PDCP COUNTs to 0 and activates the new AS keys in PDCP layer and then sends the RRC Connection Resume Complete message both integrity protected and ciphered to the target eNB on SRB1. Security is fully resumed on UE side after reception and processing of RRC connection resume message. The UE can receive data on DRB(s) after having received and processed RRC connection resume message. UL data on DRB(s) can be sent after RRC Connection Resume Complete message. After a successful resume the target eNB shall perform Path Switch procedure as is done in case of X2-handover. When EDT feature is used, the following handling shall apply to the RRC Connection Resume procedure. For protection of the UL EDT data in the RRC Connection Resume Request message and all other RRC messages following the RRC Connection Resume Request message except RRC Connection Reject, the UE and the source eNB shall derive a new KeNB*. This new KeNB* shall be derived using the target PCI, target EARFCN-DL and the KeNB/NH based on either a horizontal key derivation or a vertical key derivation (as defined in Clause 7.2.8.1.1 and Annex A.5) according to the NCC value sent to the UE in the RRC Connection Suspend message. The UE and the target eNB shall further derive new AS keys KRRCint, KRRCenc, and KUPenc from the newly derived KeNB*. The UE and the target eNB shall use the newly derived KUPenc for ciphering/deciphering of the UL EDT data in PDCP layer in the RRC Connection Resume Request message, and user DL data (if included) in PDCP layer in the RRC Connection Suspend or RRC Connection Resume message. The calculation and verification of the ShortResumeMAC-I shall use the (old) KRRCint used in the source cell. Further, in case of EDT, the RRC Connection Resume message sent by the target eNB to the UE shall be both integrity protected and ciphered in PDCP layer using the new AS keys (KRRCint, KRRCenc) derived from the new KeNB*. In this case, the UE shall ignore the NCC value in RRC Connection Resume message and shall not change its KeNB. The UE may receive an RRC Connection Reject message with suspend indication, instead of RRC Connection Resume message. In that case, for the next resume to any target eNB, the UE shall start with the same AS security context as it had when it was suspended originally, i.e., same KeNB/NH shall act as base key for derivation of new KeNB*.

The target eNB may be the same as the source eNB in the description in the previous clause. If so the single eNB performs the roles of both the source and target eNB. In particular, a new KeNB* shall be derived even if the UE is resuming to the same cell from where it was suspended. However, there is the following difference. After a successful resume the eNB shall send S1-AP UE Context Resume Request message to the MME. Upon reception of the S1-AP UE Context Resume Request message the MME shall check its local policy. If the local policy in the MME indicates that a new NH derivation is needed, the MME shall increase its locally kept NCC value by one and compute a fresh NH from its stored data using the function defined in Annex A.4. The MME shall store that fresh pair and send it to the eNB in the S1-AP UE Context Resume Response message. Upon receipt of the S1-AP UE Context Resume Response message from the MME and if the message includes a {NH, NCC} pair, the eNB shall store the fresh{NH, NCC} pair in the S1-AP UE Context Resume Response message and remove any existing unused stored {NH, NCC} pairs. The {NH, NCC} pair may be used in the next suspend/resume or X2-handover procedures. When EDT feature is used, the single eNB performs the roles of both the source and target eNB as described in Clause 7.2.11.3.