Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 33.102  Word version:  16.0.0

Top   Top   Up   Prev   Next
1…   4   5…   6…   6.4…   6.5…   6.6…   6.8…   6.8.4…   6.8.8…   8…   B…   C…   F…

 

6.4  Local authentication and connection establishment

Local authentication is obtained by integrity protection functionality.

6.4.1  Cipher key and integrity key setting

Authentication and key setting are triggered by the authentication procedure and described in 6.3. Authentication and key setting may be initiated by the network as often as the network operator wishes. Key setting can occur as soon as the identity of the mobile subscriber (i.e. P-TMSI, TMSI or IMSI) is known by the VLR/SGSN. The CK and IK are stored in the VLR/SGSN and transferred to the RNC when needed. The CK and IK for the CS domain are stored on the USIM and updated at the next authentication from this domain as specified in subclause 6.8.1.5. The CK and IK for the PS domain are stored on the USIM and updated at the next authentication from this domain as specified in subclause 6.8.1.5.
If an authentication procedure is performed during a connection (PS or CS mode), the new cipher key CK and integrity key IK shall be taken in use in both the RNC and the ME as part of the security mode set-up procedure (see 6.4.5) that follows the authentication procedure.
Up

6.4.2  Ciphering and integrity mode negotiation

When an MS wishes to establish a connection with the network, the MS shall indicate to the network in the MS/USIM Classmark which cipher and integrity algorithms the MS supports. This information itself must be integrity protected. As it is the case that the RNC does not have the integrity key IK when receiving the MS/USIM Classmark this information must be stored in the RNC. The data integrity of the classmark is performed, during the security mode set-up procedure by use of the most recently generated IK (see clause 6.4.5).
The network shall compare its integrity protection capabilities and preferences, and any special requirements of the subscription of the MS, with those indicated by the MS and act according to the following rules:
  1. If the MS and the network have no versions of the UIA algorithm in common, then the connection shall be released.
  2. If the MS and the network have at least one version of the UIA algorithm in common, then the network shall select one of the mutually acceptable versions of the UIA algorithm for use on that connection.
The network shall compare its ciphering capabilities and preferences, and any special requirements of the subscription of the MS, with those indicated by the MS and act according to the following rules:
  1. If the MS and the network have no versions of the UEA algorithm in common and the network is not prepared to use an unciphered connection, then the connection shall be released.
  2. If the MS and the network have no versions of the UEA algorithm in common and the user (respectively the user's HE) and the network are willing to use an unciphered connection, then an unciphered connection shall be used.
  3. If the MS and the network have at least one version of the UEA algorithm in common, then the network shall select one of the mutually acceptable versions of the UEA algorithm for use on that connection.
Because of the separate mobility management for CS and PS services, one CN domain may, independent of the other CN, establish a connection to one and the same MS. Change of ciphering and integrity mode (algorithms) at establishment of a second MS to CN connection shall not be permitted. The preferences and special requirements for the ciphering and integrity mode setting shall be common for both domains. (e.g. the order of preference of the algorithms).
Up

6.4.3  Cipher key and integrity key lifetimeWord‑p. 30
Authentication and key agreement, which generates cipher/integrity keys, is not mandatory at call set-up, and there is therefore the possibility of unlimited and malicious re-use of compromised keys. A mechanism is needed to ensure that a particular cipher/integrity key set is not used for an unlimited period of time, to avoid attacks using compromised keys. The UE shall therefore contain a mechanism to limit the amount of data that is protected by an access link key set. For this purpose, a value called THRESHOLD is set by the operator, stored in the USIM and read out by the ME upon power on. Each time an RRC connection is released the values STARTCS and STARTPS of the bearers that were protected in that RRC connection are compared with THRESHOLD. If STARTCS and/or STARTPS are greater than or equal to THRESHOLD, the ME sets the START value in the ME for the corresponding core network domain(s) to zero, deletes the cipher key and the integrity key stored on the USIM and the ME and sets the KSI to invalid (refer to clause 6.4.4). Otherwise, the STARTCS and STARTPS are stored in the ME.
The ME shall write back the values of STARTCS and/or STARTPS to the USIM only when the UE is about to power off in a controlled manner and there are valid UTRAN keys for that domain.
When the UE has powered on and before attempting to connect to any network, the ME reads the START values from the USIM and stores them in the volatile memory of ME. If STARTCS and/or STARTPS read from the USIM are greater than or equal to THRESHOLD or the KSI on the USIM is invalid, the ME sets the START value in the ME for the corresponding core network domain(s) to zero. The ME then marks the START values in the USIM as invalid by setting STARTCS and STARTPS to THRESHOLD. In addition for the former case, the ME deletes the cipher key and the integrity key stored on the USIM and sets the KSI to invalid (refer to clause 6.4.4).
When an RRC connection is established the ME uses the START values from the volatile memory of the ME. The ME shall trigger the generation of a new access link key set (a cipher key and an integrity key) for a core network domain if either the START value for that domain in the ME is greater than or equal to THRESHOLD or if there are no valid keys in the ME nor in the USIM for that domain. In addition for the former case, the ME deletes the cipher key and the integrity key stored on the USIM, sets the KSI to invalid (refer to clause 6.4.4) and sets the corresponding START value(s) in the ME to zero.
This mechanism will ensure that a cipher/integrity key set cannot be reused beyond the limit set by the operator.
When the user is attached to a UTRAN, a R99+ ME with a SIM inserted shall use a default value for maximum value of STARTCS or STARTPS as described in clause 6.8.2.4. This maximum value of STARTCS or STARTPS corresponds to THRESHOLD as described in the present clause.
Up

6.4.4  Cipher key and integrity key identification

The key set identifier (KSI) is a number which is associated with the cipher and integrity keys derived during authentication. The key set identifier is allocated by the network and sent with the authentication request message to the mobile station where it is stored together with the calculated cipher key CK and integrity key IK. KSI in UMTS corresponds to CKSN in GSM. The USIM stores one KSI/CKSN for the PS domain key set and one KSI/CKSN for the CS domain key set.
The purpose of the key set identifier is to make it possible for the network to identify the cipher key CK and integrity key IK which are stored in the mobile station without invoking the authentication procedure. This is used to allow re-use of the cipher key CK and integrity key IK during subsequent connection set-ups.
KSI and CKSN have the same format. The key set identifier is three bits. Seven values are used to identify the key set. A value of '111' is used by the mobile station to indicate that a valid key is not available for use. At deletion of the cipher key and integrity key, the KSI is set to '111'. The value '111' in the other direction from network to mobile station is reserved.
Up

6.4.5  Security mode set-up procedureWord‑p. 31
This clause describes one common procedure for both ciphering and integrity protection set-up. It is mandatory to start integrity protection of signalling messages by use of this procedure at each new signalling connection establishment between MS and VLR/SGSN. The five exceptions when it is not mandatory to start integrity protection are:
  • If the only purpose with the signalling connection establishment and the only result is periodic location registration, i.e. no change of any registration information.
  • If there is no MS-VLR/SGSNsignalling after the initial L3 signalling message sent from MS to VLR/SGSN, i.e. in the case of deactivation indication sent from the MS followed by connection release.
  • If the only MS-VLR/SGSN signalling after the initial L3 signalling message sent from MS to VLR/SGSN, and possible user identity request and authentication (see below), is a reject signalling message followed by a connection release. However, it shall be mandatory for the VLR/SGSN to start integrity protection before sending a reject signalling message that causes the CSG list on the UE to be modified.
  • If the call is an emergency call teleservice as defined in TS 22.003, see clause 6.4.9.2 below.
  • If the PS connection establishment is for an emergency session, see clause 6.4.9.2 below.
When the integrity protection shall be started, the only procedures between MS and VLR/SGSN that are allowed after the initial connection request (i.e. the initial Layer 3 message sent to VLR/SGSN) and before the security mode set-up procedure are the following:
  • Identification by a permanent identity (i.e. request for IMSI, IMEI or IMEISV), and
  • Authentication and key agreement.
The message sequence flow below describes the information transfer at initial connection establishment, possible authentication and start of integrity protection and possible ciphering.
[not reproduced yet]
Figure 14: Local authentication and connection set-up
Up
Detailed description of the flow above:
Step 1.
RRC connection establishment includes the transfer from MS to RNC of the ME security capability optionally the GSM Classmarks 2 and 3 and the START values for the CS service domain respective the PS service domain. The UE security capability information includes the ciphering capabilities (UEAs) and the integrity capabilities (UIAs) of the MS. The START values and the UE security capability information are stored in the SRNC. If the GSM Clasmarks 2 and 3 are transmitted during the RRC Connection establishment, the RNC must store the GSM ciphering capability of the UE (see also message 7).
Step .
The MS sends the Initial L3 message (Location update request, CM service request, Routing area update request, attach request, paging response etc.) to the VLR/SGSN. This message contains e.g. the user identity and the KSI. The included KSI (Key Set Identifier) is the KSI allocated by the CS service domain or PS service domain at the last authentication for this CN domain.
Step 3.
User identity request may be performed (see 6.2). Authentication of the user and generation of new security keys (IK and CK) may be performed (see 6.3.3). A new KSI will then also be allocated.
Step 4.
The VLR/SGSN determines which UIAs and UEAs that are allowed to be used in order of preference.
Step 5.
The VLR/SGSN initiates integrity and ciphering by sending the RANAP message Security Mode Command to SRNC. This message contains an ordered list of allowed UIAs in order of preference, and the IK to be used. If ciphering shall be started, it contains the ordered list of allowed UEAs in order of preference, and the CK to be used. If a new authentication and security key generation has been performed (see 3 above), this shall be indicated in the message sent to the SRNC. The indication of new generated keys implies that the START value to be used shall be reset (i.e. set to zero) at start use of the new keys. Otherwise, it is the START value already available in the SRNC that shall be used (see 1. above). VLR/SGSN shall treat the keyset as "new" only if the authentication and security key generation was performed while in UTRAN, and the keyset has not been used for this UE in a previous successful RANAP Security Mode Control, BSSMAP Cipher Mode Control procedure or in a successful Handover/Relocation, otherwise the keyset shall be considered to be "old".
Step 6.
The SRNC decides which algorithms to use by selecting the highest preference algorithm from the list of allowed algorithms that matches any of the algorithms supported by the MS (see 6.4.2). The SRNC generates a random value FRESH and initiates the downlink integrity protection. If the requirements received in the Security mode command can not be fulfilled, the SRNC sends a SECURITY MODE REJECT message to the requesting VLR/SGSN. The further actions are described in 6.4.2.
Step 7.
The SRNC generates the RRC message Security mode command. The message includes the ME security capability, optionally the GSM ciphering capability (if received during RRC Connection establishment), the UIA and FRESH to be used and if ciphering shall be started also the UEA to be used. Additional information (start of ciphering) may also be included. Because of that the MS can have two ciphering and integrity key sets, the network must indicate which key set to use. This is obtained by including a CN type indicator information in the Security mode command message. Before sending this message to the MS, the SRNC generates the MAC-I (Message Authentication Code for Integrity) and attaches this information to the message.
Step 8.
At reception of the Security mode command message, the MS controls that the "UE security capability" received is equal to the "UE security capability" sent in the initial message. The same applies to the GSM ciphering capability if it was included in the RRC Connection Establishment. The MS computes XMAC-I on the message received by using the indicated UIA, COUNT-I generated from the stored START and the received FRESH parameter. The MS verifies the integrity of the message by comparing the received MAC-I with the generated XMAC-I.
Step 9.
If all controls are successful, the MS compiles the RRC message Security mode complete and generates the MAC-I for this message. If any control is not successful, the procedure ends in the MS.
Step 10.
At reception of the response message, the SRNC computes the XMAC-I on the message. The SRNC verifies the data integrity of the message by comparing the received MAC-I with the generated XMAC-I.
Step 11.
The transfer of the RANAP message Security Mode Complete response, including the selected algorithms, from SRNC to the VLR/SGSN ends the procedure.
The Security mode command to MS starts the downlink integrity protection, i.e. this and all following downlink messages sent to the MS are integrity protected using the new integrity configuration. The Security mode complete from MS starts the uplink integrity protection, i.e. this and all following messages sent from the MS are integrity protected using the new integrity configuration. When ciphering shall be started, the Ciphering Activation time information that is exchanged between SRNC and MS during the Security mode set-up procedure sets the RLC Sequence Number/Connection Frame Number when to start ciphering in Downlink respective Uplink using the new ciphering configuration.
Mechanisms are defined to allow networks to overcome early UE implementation faults [22]. A potential early UE implementation fault could be a faulty UEA1 implementation. To allow networks to handle early UEs which have faulty UEA1 implementations, the SGSN/VLR may configure the security mode command based on the UE's IMEISV so that certain UEs which claim to support UEA1 shall have security established without ciphering (i.e. with UEA0), while other UEs which claim to support UEA1 shall have security established with ciphering (i.e. with UEA1). This procedure shall involve the SGSN/VLR retrieving the IMEISV from the UE before the security mode set-up procedure has started.
If the above procedure to handle UEs which have faulty UEA1 implementations is implemented and the security mode set-up procedure results in security being established without ciphering (i.e. with UEA0) then the SGSN/VLR shall request the IMEISV from the UE for a second time immediately after the security mode set-up procedure has been completed. This second IMEISV request is integrity protected. If the IMEISV request is not successful, or if the second IMEISV received is different from the IMEISV received before the security mode set-up procedure was started then the connection shall be released.
Up

6.4.6  Signalling procedures in the case of an unsuccessful integrity checkWord‑p. 34
The supervision of failed integrity checks shall be performed both in the MS and the SRNC. In case of failed integrity check (i.e. faulty or missing MAC) is detected after that the integrity protection is started the concerned message shall be discarded. This can happen on the RNC side or on the MS side.

6.4.7  Signalling procedure for periodic local authentication

The following procedure is used by the RNC to periodically perform a local authentication. At the same time, the amount of data sent during the RRC connection is periodically checked by the RNC and the UE. The RNC is monitoring the COUNT-C value associated to each radio bearer. The procedure is triggered whenever any of these values reaches a critical checking value. The granularity of these checking values and the values themselves are defined by the visited network. All messages in the procedure are integrity protected.
[not reproduced yet]
Figure 15a: RNC periodic local authentication procedure
Up
  1. When a checking value is reached (e.g. the value in some fixed bit position in the hyperframe number is changed), a Counter Check message is sent by the RNC. The Counter Check message contains the most significant parts of the COUNT-C values (which reflect amount of data sent and received) from each active radio bearer.
  2. The UE compares the COUNT-C values received in the Counter Check message with the values of its radio bearers. Different UE COUNT-C values are included within the Counter Check Response message.
  3. If the RNC receives a counter check response message that does not contain any COUNT-C values, the procedure ends. If the RNC receives a counter check response that contains one or several COUNT-C values, the RNC may release the connection.
Up

6.4.8  Initialisation of synchronisation for ciphering and integrity protection

The ciphering and integrity protection algorithms are driven by counters (COUNT-C and COUNT-I) that at connection establishment need to be initialised. For that purpose the ME and the USIM have the ability to store a START value. The ME and the USIM store a STARTCS value for the CS cipher/integrity keys and a STARTPS value for the PS cipher/integrity keys. The length of START is 20 bits.
The ME only contains (valid) START values when it is powered-on and a USIM is inserted. When the ME is powered-off or the USIM is removed, the ME deletes its START values and the Kc 128 if one was derived. After power-on or insertion of a USIM, the USIM sends its START values to the ME, and the ME stores them.
At radio connection establishment for a particular serving network domain (CS or PS) the ME sends the STARTCS and the STARTPS value to the RNC in the RRC connection setup complete message.
The ME and the RNC initialise the 20 most significant bits of the RRC HFN (for integrity protection), the RLC HFN (for ciphering) and the MAC-d HFN (for ciphering) to the START value of the corresponding service domain; the remaining bits are initialised to 0. Also the RRC SN (for integrity protection) and the RLC SN (for ciphering) are initialised to 0.
During an ongoing radio connection, the STARTCS value in the ME and in the SRNC is defined as the 20 most significant bits of the maximum of all current COUNT-C and COUNT-I values for all signalling radio bearers and CS user data radio bearers protected using CK CS and/or IK CS, incremented by2, i.e.:
STARTCS' = MSB20 ( MAX {COUNT-C, COUNT-I | all radio bearers (including signalling) protected with CK CS and IK CS}) +2.
  • If current STARTCS < STARTCS' then STARTCS = STARTCS', otherwise STARTCS is unchanged.
Likewise, during an ongoing radio connection, the STARTPS value in the ME and in the SRNC is defined as the 20 most significant bits of the maximum of all current COUNT-C and COUNT-I values for all signalling radio bearers and PS user data radio bearers protected using CK PS and/or IK PS, incremented by2, i.e.:
STARTPS' = MSB20 ( MAX {COUNT-C, COUNT-I | all radio bearers (including signalling) protected with CK PS and IK PS}) +2.
  • If current STARTPS < STARTPS' then STARTPS = STARTPS', otherwise STARTPS is unchanged.
If any of the COUNT-C or COUNT-I assigned to the radio bearers of the same CN domain reaches its maximum value, the ME and SRNC shall set START of the corresponding CN domain to its maximum value.
The handling of the START values for new keys obtained from an authentication and key agreement run is described in clause 4.1.1.8 of TS 24.008 and clause 8.1.12.3.1 of TS 25.331.
Up

6.4.9  Emergency call handlingWord‑p. 35
PLMNs shall support an emergency call teleservice as defined in TS 22.003 which fulfils the additional service requirements defined in TS 22.101.
The PS domain of a PLMN may support establishment of PS connections for the purposes of IP multimedia subsystem emergency sessions as defined in TS 23.167 which fullfills service requirements defined in TS 22.101. IMS Emergency Session Support in the PS domain is specified in TS 23.060.
Up

6.4.9.1  Security procedures applied

The security mode procedure shall be applied as part of emergency call establishment, or PS connection establishment for an emergency session, as defined in TS 24.008. Thus, integrity protection (and optionally ciphering) shall be applied as for a non-emergency call or non-emergency related PS connection. If authentication of the (U)SIM fails for any reason, the emergency call or PS connection establishment for emergency session shall proceed as in 6.4.9.2 d) below. Once the call, or PS connection, is in progress with integrity protection (and optionally ciphering) applied, failure of integrity checking or ciphering is an unusual circumstance and must be treated in the same manner as other equipment failures, that is, the call, or emergency related PS connection, will terminate.
Up

6.4.9.2  Security procedures not applied

As a serving network option, emergency calls, or PS connections for emergency sessions, may be established without the network having to apply the security mode procedure as defined in TS 24.008.
The following are the only cases where the "security procedure not applied" option may be used:
  1. Authentication is impossible because the (U)SIM is absent;
  2. Authentication is impossible because the serving network cannot obtain authentication vectors due to a network failure;
  3. Authentication is impossible because the (U)SIM is not permitted to receive non-emergency services from the serving network (e.g. there is no roaming agreement or the IMSI is barred);
  4. Authentication is possible but the serving network cannot successfully authenticate the (U)SIM.
Up


Up   Top   ToC