Wednesday 13 July 2016

NAS security (as per spec:24.301)

          NAS security

4.4.1  General

This clause describes the principles for the handling of EPS security contexts in the UE and in the MME and the procedures used for the security protection of EPS NAS messages between UE and MME. Security protection involves integrity protection and ciphering of the EMM and ESM NAS messages.
The signalling procedures for the control of NAS security are part of the EMM protocol and are described in detail in clause 5.
NOTE:      The use of ciphering in a network is an operator option. In this subclause, for the ease of description, it is assumed that ciphering is used, unless explicitly indicated otherwise. Operation of a network without ciphering is achieved by configuring the MME so that it always selects the "null ciphering algorithm", EEA0.

4.4.2  Handling of EPS security contexts

4.4.2.1            General

The security parameters for authentication, integrity protection and ciphering are tied together in an EPS security context and identified by a key set identifier for E-UTRAN (eKSI). The relationship between the security parameters is defined in 3GPP TS 33.401 [19].
Before security can be activated, the MME and the UE need to establish an EPS security context. Usually, the EPS security context is created as the result of an authentication procedure between MME and UE. Alternatively, during inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE derive a mapped EPS security context from a UMTS security context that has been established while the UE was in A/Gb mode or Iu mode.
The key set identifier eKSI is assigned by the MME either during the authentication procedure or, for the mapped security context, during the handover procedure. The eKSI consists of a value and a type of security context parameter indicating whether an EPS security context is a native EPS security context or a mapped EPS security context. When the EPS security context is a native EPS security context, the eKSI has the value of KSIASME, and when the current EPS security context is a mapped EPS security context, the eKSI has the value of KSISGSN.
The eKSI can be used to establish the secure exchange of NAS messages at the next establishment of a NAS signalling connection without executing a new authentication procedure (see subclause 4.4.2.3).To this purpose the initial NAS messages (ATTACH REQUEST, TRACKING AREA UPDATE REQUEST, DETACH REQUEST, SERVICE REQUEST and EXTENDED SERVICE REQUEST) and the SECURITY MODE COMMAND message contain an eKSI in the NAS key set identifier IE or the value part of eKSI in the KSI and sequence number IE indicating the current EPS security context used to integrity protect the message.
In the present document, when the UE is required to delete an eKSI, the UE shall set the eKSI to the value "no key is available" and consider also the associated keys KASME or K'ASME , EPS NAS ciphering key and EPS NAS integrity key invalid (i.e. the EPS NAS security context associated with the eKSI as no longer valid).
NOTE:      In some specifications the term ciphering key sequence number might be used instead of the term Key Set Identifier (KSI).
The EPS security context is taken into use, when the MME initiates a security mode control procedure or, if it is a mapped EPS security context, during the inter-system handover procedure. The security context which has been taken into use by the network most recently is called current security context.
The UE and the MME need to be able to maintain two EPS security contexts simultaneously, since:
-     after a re-authentication, the UE and the MME can have both a current EPS security context and a non-current EPS security context which has not yet been taken into use; and
-     after an inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the UE and the MME can have both a mapped EPS security context which is the current EPS security context and a native EPS security context that was created during a previous access in S1 mode or S101 mode.
The number of EPS security contexts that need to be maintained simultaneously by the UE and the MME is limited by the following requirements:
-     After a successful (re-)authentication, the MME and the UE shall delete any old EPS security context different from the current EPS security context.
-     When a new EPS security context is taken into use through a security mode control procedure, the MME and the UE shall delete the previously current EPS security context.
-     When a new EPS security context is taken into use during the inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall not delete the previously current native EPS security context.
-     When the MME and the UE derive a new mapped EPS security context during inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, the MME and the UE shall delete any existing mapped EPS security context.
-     When a native EPS security context is taken into use, the MME and the UE shall delete any mapped EPS security context.
When the UE moves from EMM-CONNECTED to EMM-IDLE, it shall storethe current EPS security context as specified in annex C.
The UE shall mark the EPS security context (stored according to annex C) as invalid:
-     when the UE moves from EMM-IDLE to EMM-CONNECTED; or
-     when the UE moves from EMM-DEREGISTERED to EMM-REGISTERED.

4.4.2.2            Establishment of a mapped EPS security context during intersystem handover

In order for the UE to derive a mapped EPS security context for an inter-system change from A/Gb mode or Iu mode to S1 mode in EMM-CONNECTED mode, the MME shall generate a KSISGSN, create a nonceMME and generate the K'ASME using the created nonceMME as indicated in 3GPP TS 33.401 [19]. The MME shall include the selected NAS algorithms, nonceMME and generated KSISGSN(associated with the K'ASME) in the NAS security transparent container for handover to E-UTRAN. The MME shall derive the EPS NAS keys from K'ASMEand the MME shall set the uplink and downlink NAS COUNT counters of the mapped EPS security context to zero.

4.4.2.3            Establishment of secure exchange of NAS messages

Secure exchange of NAS messages via a NAS signalling connection is usually established by the MME during the attach procedure by initiating a security mode control procedure. After successful completion of the security mode control procedure, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged between the UE and the MME are sent integrity protected and ciphered using the current EPS security algorithm.
During inter-system handover from A/Gb mode to S1 mode or Iu mode to S1 mode, secure exchange of NAS messages is established between the MME and the UE by:
-     the transmission of NAS security related parameters encapsulated in the AS signalling from the MME to the UE triggering the inter-system handover (see 3GPP TS 33.401 [19]). The UE uses these parameters to generate the mapped EPS security context; and,
-     after the handover, the transmission of a TRACKING AREA UPDATE REQUEST message from the UE to the MME. The UE shall send this message integrity protected using the mapped EPS security context, but unciphered. From this time onward, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged between the UE and the MME are sent integrity protected and ciphered using the mapped EPS security context.
The secure exchange of NAS messages shall be continued after S1 mode to S1 mode handover. It is terminated after inter-system handover from S1 mode to A/Gb mode or Iu mode or when the NAS signalling connection is released.
When a UE in EMM-IDLE mode establishes a new NAS signalling connection and has a valid current EPS security context, secure exchange of NAS messages can be re-established in the following ways:
1)   Except for the case described in item 3 below, the UE shall transmit the initial NAS message integrity protected with the current EPS security context, but unciphered. The UE shall include the eKSI indicating the current EPS security context value in the initial NAS message. The MME shall check whether the eKSI included in the initial NAS message belongs to an EPS security context available in the MME, and shall verify the MAC of the NAS message. If the verification is successful, the MME may re-establish the secure exchange of NAS messages:
-     by replying with a NAS message that is integrity protected and ciphered using the current EPS security context. From this time onward, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged between the UE and the MME are sent integrity protected and ciphered; or
-     by initiating a security mode control procedure. This can be used by the MME to take a non-current EPS security context into use or to modify the current EPS security context by selecting new NAS security algorithms; or
2)   If the initial NAS message was a SERVICE REQUEST message or EXTENDED SERVICE REQUEST message, secure exchange of NAS messages is triggered by the indication from the lower layers that the user plane radio bearers are successfully set up. After successful completion of the procedure, except for the messages specified in subclauses 4.4.4 and 4.4.5, all NAS messages exchanged between the UE and the MME are sent integrity protected and ciphered.
3)   If the UE has no current EPS security context and performs a tracking area updating procedure after an inter-system change in idle mode from A/Gb mode to S1 mode or Iu mode to S1 mode, the UE shall send the TRACKING AREA UPDATE REQUEST message without integrity protection and encryption. The UE shall include a nonce and a GPRS ciphering key sequence number for creation of a mapped security context. The MME creates a fresh mapped EPS security context and takes this context into use by initiating a security mode control procedure. This re-establishes the secure exchange of NAS messages.

4.4.2.4            Change of security keys

When the MME initiates a re-authentication to create a new EPS security context, the messages exchanged during the authentication procedure are integrity protected and ciphered using the current EPS security context, if any.
Both UE and MME shall continue to use the current EPS security context, until the MME initiates a security mode control procedure. The SECURITY MODE COMMAND message sent by the MME includes the eKSI of the new EPS security context to be used. The MME shall send the message integrity protected with the new EPS security context, but unciphered. When the UE responds with a SECURITY MODE COMPLETE, it shall send the message integrity protected and ciphered with the new EPS security context.
The MME can also modify the current EPS security context or take an existing native EPS security context into use, by sending a SECURITY MODE COMMAND message including the eKSI of the EPS security context to be modified and including a new set of selected NAS security algorithms. In this case the MME shall send the SECURITY MODE COMMAND message integrity protected with the modified EPS security context, but unciphered. When the UE replies with a SECURITY MODE COMPLETE message, it shall send the message integrity protected and ciphered with the modified EPS security context.

4.4.3  Handling of NAS COUNT and NAS sequence number

4.4.3.1            General

Each EPS NAS security context shall be associated with two separate counters NAS COUNT: one related to uplink NAS messages and one related to downlink NAS messages. The NAS COUNT counters use 24 bit internal representation and are independently maintained by UE and MME. The NAS COUNT shall be constructed as a NAS sequence number (8 least significant bits) concatenated with a NAS overflow counter (16 most significant bits).
When NAS COUNT is input to NAS ciphering or NAS integrity algorithms it shall be considered to be a 32-bit entity which shall be constructed by padding the 24-bit internal representation with 8 zeros in the most significant bits.
During the handover from UTRAN/GERAN to E-UTRAN, if the mapped EPS security context is taken into use, the NAS COUNT values for this EPS security context shall be initialized to zero in the UE and the network for uplink and downlink NAS messages.
The NAS sequence number part of the NAS COUNT shall be exchanged between the UE and the MME as part of the NAS signalling. After each new or retransmitted outbound security protected NAS message, the sender shall increase the NAS COUNT number by one. Specifically, on the sender side, the NAS sequence number shall be increased by one, and if the result is zero (due to wrap around), the NAS overflow counter shall also be incremented by one (see subclause 4.4.3.5). The receiving side shall estimate the NAS COUNT used by the sending side. Specifically, if the estimated NAS sequence number wraps around, the NAS overflow counter shall be incremented by one.
In some NAS messages only 5 of the 8 NAS sequence number bits are transmitted. When this is the case, the receiver shall estimate the remaining 3 most significant bits of the sequence number.

4.4.3.2            Replay protection

Replay protection shall be supported for received NAS messages both in the MME and the UE. However, since the realization of replay protection does not affect the interoperability between nodes, no specific mechanism is required for implementation.
Replay protection must assure that one and the same NAS message is not accepted twice by the receiver. Specifically, for a given NAS security context, a given NAS COUNT value shall be accepted at most one time and only if message integrity verifies correctly.

4.4.3.3            Integrity protection and verification

The sender shall use its locally stored NAS COUNT as input to the integrity protection algorithm.
The receiver shall use the NAS sequence number included in the received message (or estimated from the 5 bits of the NAS sequence number received in the message) and an estimate for the NAS overflow counter as defined in subclause 4.4.3.1 to form the NAS COUNT input to the integrity verification algorithm.
The algorithm to calculate the integrity protection information is specified in 3GPP TS 33.401 [19], and the integrity protection shall include octet 6 to n of the security protected NAS message, i.e. the sequence number IE and the NAS message IE. In addition to the data that is to be integrity protected, the constant BEARER ID, DIRECTION bit, NAS COUNT and NAS integrity key are input to the integrity protection algorithm. These parameters are described in 3GPP TS 33.401 [19].
After successful integrity protection validation, the receiver shall update its corresponding locally stored NAS COUNT with the value of the estimated NAS COUNT for this NAS message.

4.4.3.4            Ciphering and deciphering

The sender shall use its locally stored NAS COUNT as input to the ciphering algorithm.
The receiver shall use the NAS sequence number included in the received message (or estimated from the 5 bits of the NAS sequence number received in the message) and an estimate for the NAS overflow counter as defined in subclause 4.4.3.1 to form the NAS COUNT input to the deciphering algorithm.
The input parameters to the NAS ciphering algorithm are the constant BEARER ID, DIRECTION bit, NAS COUNT, NAS encryption key and the length of the key stream to be generated by the encryption algorithm.

4.4.3.5            NAS COUNT wrap around

If, when increasing the NAS COUNT as specified above, the MME detects that its NAS COUNT is "close" to wrap around, (close to 224), the MME shall initiate a new AKA procedure with the UE, leading to a new established NAS security context and the NAS COUNT being reset to 0 in both the UE and the MME when the new NAS security context is activated as discussed above.
Similarly, the MME shall initiate an AKA procedure if it detects that the UE's uplink NAS COUNT is close to wrap around. If for some reason a new KASME has not been established using AKA before the NAS COUNT wraps around, the node (MME or UE) in need of sending a NAS message shall instead release the NAS signalling connection. Prior to sending the next uplink NAS message, the UE shall delete the eKSI indicating the current EPS security context.

4.4.4  Integrity protection of NAS signalling messages

4.4.4.1            General

For the UE, integrity protected signalling is mandatory for the NAS messages once a valid EPS security context exists and has been taken into use. For the network, integrity protected signalling is mandatory for the NAS messages once a secure exchange of NAS messages has been established for the NAS signalling connection. Integrity protection of all NAS signalling messages is the responsibility of the NAS. It is the network which activates integrity protection.
Details of the integrity protection and verification of NAS signalling messages are specified in 3GPP TS 33.401 [19].
When both ciphering and integrity protection are activated, the NAS message is first encrypted and then the encrypted NAS message and the NAS sequence number are integrity protected by calculating the MAC.
When only integrity protection is activated, and ciphering is not activated, the unciphered NAS message and the NAS sequence number are integrity protected by calculating the MAC.
When during the EPS attach procedure an ESM message is piggybacked in an EMM message, there is only one sequence number IE and one message authentication code IE, if any, for the combined NAS message.

4.4.4.2            Integrity checking of NAS signalling messages in the UE

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the UE or forwarded to the ESM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:
-     EMM messages:
-     IDENTITY REQUEST (if requested identification parameter is IMSI);
-     AUTHENTICATION REQUEST;
-     AUTHENTICATION REJECT;
-     ATTACH REJECT;
-     DETACH REQUEST;
-     DETACH ACCEPT (for non switch off);
-     TRACKING AREA UPDATE REJECT;
-     SERVICE REJECT.
NOTE:      These messages are accepted by the UE without integrity protection, as in certain situations they are sent by the network before security can be activated.
All ESM messages are integrity protected.
Once the secure exchange of NAS messages has been established, the receiving EMM or ESM entity in the UE shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If NAS signalling messages, having not successfully passed the integrity check, are received, then the NAS in the UE shall discard that message. If any NAS signalling message is received as not integrity protected even though the secure exchange of NAS messages has been established by the network, then the NAS shall discard this message.

4.4.4.3            Integrity checking of NAS signalling messages in the MME

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity in the MME or forwarded to the ESM entity, unless the secure exchange of NAS messages has been established for the NAS signalling connection:
-     EMM messages:
-     ATTACH REQUEST;
-     IDENTITY RESPONSE (if requested identification parameter is IMSI);
-     AUTHENTICATION RESPONSE;
-     AUTHENTICATION FAILURE;
-     SECURITY MODE REJECT;
-     DETACH REQUEST;
-     DETACH ACCEPT;
-     TRACKING AREA UPDATE REQUEST.
NOTE 1:   The TRACKING AREA UPDATE REQUEST message is sent by the UE without integrity protection, if the tracking area updating procedure is initiated due to an inter-system change in idle mode and no current EPS security context is available in the UE. The other messages are accepted by the MME without integrity protection, as in certain situations they are sent by the UE before security can be activated.
All ESM messages are integrity protected except a PDN CONNECTIVITY REQUEST message if it is sent piggybacked in ATTACH REQUEST message and NAS security is not activated.
Once a current EPS security context exists, until the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving EMM entity in the MME shall process the following NAS signalling messages, even if the MAC included in the message fails the integrity check or cannot be verified, as the EPS security context is not available in the network:
-     ATTACH REQUEST;
-     IDENTITY RESPONSE (if requested identification parameter is IMSI);
-     AUTHENTICATION RESPONSE;
-     AUTHENTICATION FAILURE;
-     SECURITY MODE REJECT;
-     DETACH REQUEST (if sent before security has been activated);
-     DETACH ACCEPT;
-     TRACKING AREA UPDATE REQUEST;
-     SERVICE REQUEST;
-     EXTENDED SERVICE REQUEST.
NOTE 2:   These messages are processed by the MME even when the MAC that fails the integrity check or cannot be verified, as in certain situations they can be sent by the UE protected with an EPS security context that is no longer available in the network.
If an ATTACH REQUEST message fails the integrity check, the MME shall authenticate the subscriber before processing the attach request any further.
If a TRACKING AREA UPDATE REQUEST message fails the integrity check, the MME shall initiate a security mode control procedure to take a new mapped EPS security context into use, if the UE provided a nonceUE, GPRS ciphering key sequence number, P-TMSI and RAI in the TRACKING AREA UPDATE REQUEST message; otherwise the MME shall reject the request with EMM cause #9 "UE identity cannot be derived by the network".
If a SERVICE REQUEST or EXTENDED SERVICE REQUEST message fails the integrity check, the MME shall reject the request with EMM cause #9 "UE identity cannot be derived by the network".
Once the secure exchange of NAS messages has been established for the NAS signalling connection, the receiving EMM or ESM entity in the MME shall not process any NAS signalling messages unless they have been successfully integrity checked by the NAS. If any NAS signalling message, having not successfully passed the integrity check, is received, then the NAS in the MME shall discard that message. If any NAS signalling message is received, as not integrity protected even though the secure exchange of NAS messages has been established, then the NAS shall discard this message.

4.4.5  Ciphering of NAS signalling messages

The use of ciphering in a network is an operator option subject to MME configuration. When operation of the network without ciphering is configured, the MME shall indicate the use of "null ciphering algorithm" EEA0 (see subclause 9.9.3.23) in the current security context for all UEs. For setting the security header type in outbound NAS messages, the UE and the MME shall apply the same rules irrespective of whether the "null ciphering algorithm" or any other ciphering algorithm is indicated in the security context.
When the UE establishes a new NAS signalling connection, it shall send the initial NAS message unciphered.
The UE shall start the ciphering and deciphering of NAS messages when the secure exchange of NAS messages has been established for a NAS signalling connection. From this time onward, except for the ATTACH REQUEST message and TRACKING AREA UPDATE REQUEST message, the UE shall send all NAS messages ciphered until the NAS signalling connection is released, or the UE performs intersystem handover to A/Gb mode or Iu mode.
The MME shall start ciphering and deciphering of NAS messages as described in subclause 4.4.2.2. From this time onward, except for the SECURITY MODE COMMAND message, the MME shall send all NAS messages ciphered until the NAS signalling connection is released, or the UE performs intersystem handover to A/Gb mode or Iu mode.
Once the encryption of NAS messages has been started between the MME and the UE, the receiver shall discard the unciphered NAS messages which shall have been ciphered according to the rules described in this specification.
If the "null ciphering algorithm" EEA0 has been selected as a ciphering algorithm, the NAS messages with the security header indicating ciphering are regarded as ciphered.
Details of ciphering and deciphering of NAS signalling messages are specified in 3GPP TS 33.401 [19].

Disabling and re-enabling of UE's E-UTRA capability

When the UE supporting the A/Gb and/or Iu mode together with the S1 mode needs to stay in A/Gb or Iu mode, in order to prevent unwanted handover or cell reselection from UTRAN/GERAN to E-UTRAN, the UE shall disable the E-UTRA capability.
-     The UE shall not set the E-UTRA support bits of the MS Radio Access capability IE (see 3GPP TS 24.008 [13], subclause 10.5.5.12a), the E-UTRA support bits of Mobile Station Classmark 3 IE (see 3GPP TS 24.008 [13], subclause 10.5.1.7) and the ISR support bit of the MS network capability IE (see 3GPP TS 24.008 [13], subclause 10.5.5.12) in the ATTACH REQUEST message and the ROUTING AREA UPDATE REQUEST message after it selects GERAN or UTRAN; and
-     the UE NAS layer shall indicate the access stratum layer(s) of disabling of the E-UTRA capability.
The UE shall enable the E-UTRA capability again in the following cases:
-     the UE mode of operation changes from CS/PS mode 1 of operation to CS/PS mode 2 of operation;
-     the UE mode of operation changes from PS mode 1 of operation to PS mode 2 of operation;
-     the UE powers off and powers on again; or
-     for the PLMN selection purpose.


No comments:

Post a Comment