3GPP TSG SA WG3 — SA 3 #17 S3-010109

Gothenberg, Sweden. 27 Februar-2 March 2001.

CR-Form-v3

CHANGE REQUEST
a 33.102 CR CR-Num a rev a Current version: a
- 3.7.0
For HELP on using this form, see bottom of this page or look at the pop-up text over the a symbols.

Proposed change affects: a (U)SIM ME/UE Radio Access Network X Core Network X

Title: a GSM ciphering capability Handling in Security Mode set up procedure

Source: a Nokia

Work item code: a Security Date: a 21/2/2001

Category: a F Release: a R99

Use one of the following categories: Use one of the following releases:
F (essential correction) 2 (GSM Phase 2)
A (corresponds to a correction in an earlier release) R96 (Release 1996)
B (Addition of feature), R97 (Release 1997)
C (Functional modification of feature) R98 (Release 1998)
D (Editorial modification) R99 (Release 1999)
Detailed explanations of the above categories can REL-4 (Release 4)
be found in 3GPP TR 21.900. REL-5 (Release 5)

Reason for change: a Technical Background:

In 24.008 there are 3 different information elements "MS Classmark" specified:

MS Classmark 1, 2 and 3.

- MS Classmark 2 contains all the information needed by a UMTS core network.

- MS Classmark 1 is a short form of MS Classmark 2 and is used only for the

Location Update procedure.

- MS Classmark 3 contains information needed by the GSM BSS. The MS

Classmark 3 is *not* included in the initiating messages like CM Service Request
or Location Update Request, but only in RRC messages.

For historical reasons the fields indicating the mobile’s ciphering capabilities are
distributed between the different MS Classmarks: support of A5/1, A5/2 and A5/3
can be indicated with MS Classmark 2, but support of additional ciphering
algorithms (A5/4, ..., A5/7) can only be indicated with MS Classmark 3.

TS 33.102:

Within TS 33.102 it is needed to specify the mechanism how ciphering capability

information in Classmarks 2 and 3 are handled in UTRAN.

Summary of change: a Correct mechanism is described how UTRAN handles GSM ciphering capability

Consequences if a Mechanism described in TS 33.102 is not correctly described.

not approved:

Clauses affected: a 6.4.5; 6.8.4

Other specs a X Other core specifications a 25.331

CR page 1
affected: Test specifications
O&M Specifications

Other comments: a

How to create CRs using this form:

Comprehensive information and tips about how to create CRs can be found at: http://www.3gpp.org/3G_Specs/CRs.htm.
Below is a brief summary:
1) Fill out the above form. The symbols above marked a contain pop-up help information about the field that they are
closest to.
2) Obtain the latest version for the release of the specification to which the change is proposed. Use the MS Word
"revision marks" feature (also known as "track changes") when making the changes. All 3GPP specifications can be
downloaded from the 3GPP server under ftp://www.3gpp.org/specs/ For the latest version, look for the directory name
with the latest date e.g. 2000-09 contains the specifications resulting from the September 2000 TSG meetings.
3) With "track changes" disabled, paste the entire CR form (use CTRL-A to select it) into the specification just in front of
the clause containing the first piece of changed text. Delete those parts of the specification which are not relevant to
the change request.

CR page 2
 6.4.5 Security mode set-up procedure
This section 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 four 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.

- If the call is an emergency call teleservice as defined in TS 22.003, see section 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), 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.

CR page 3
 MS SRNC VLR/SGSN

1. RRC connection establishment including

transfer of the HFNs START values and the
UE security capability from MS to SRNC
1. Storage of HFNs START values and UE security capability
2. “Initial L3 message” with user identity, KSI etc.

3. Authentication and key generation

4 Decide allowed UIAs and UEAs

5. Security mode command (UIAs, IK, UEAs, CK, etc.)

6. Select UIA and UEA, generate FRESH

Start integrity

7. Security mode command (CN domain, UIA, FRESH,

UE security capability, UEA, MAC-I, etc.)

8. Control of UE security capability, Verify

message, Start of integrity
9. Security mode complete (MAC-I, etc.)

10. Verify received message

11. Security mode complete (selected UEA and UIA)

Start ciphering/deciphering Start ciphering/deciphering

“UE security capability” indicates UIAs and UEAs supported by MS

Figure 14: Local authentication and connection set-up

NOTE 1: The network must have the "UME security capability" information before the integrity
protection can start, i.e. the "UME security capability" must be sent to the network in an
unprotected message. Returning the "UME security capability" later on to the UME in a
protected message will give UME the possibility to verify that it was the correct "UME
security capability" that reached the network.

Detailed description of the flow above:

1. RRC connection establishment includes the transfer from MS to RNC of the UME security
capability and optionally the GSM Classmark 2M2 and CM3 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 ClassmarkM
2 and CM3 are transmitted during the RRC Connection establishment, the RNC must store the GSM
ciphering capability of the UE (see also message 7)

2. 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.

CR page 4
 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.

4. The VLR/SGSN determines which UIAs and UEAs that are allowed to be used.

5. The VLR/SGSN initiates integrity and ciphering by sending the RANAP message Security Mode
Command to SRNC. This message contains a list of allowed UIAs and the IK to be used. If
ciphering shall be started, it contains the allowed UEAs and the CK to be used. It also contains the
UE’s capability information about GSM ciphering algorithms A5/1, A5/2, A5/3 in the form of GSM
MS classmark 2. 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).

6. The SRNC decides which algorithms to use by selecting from the list of allowed algorithms, and the
list of 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.

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. If
the GSM MS classmark 2 exists, then the message shall also contain it. 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.

8. At reception of the Security mode command message, the MS controls that the “UEME security
capability” received is equal to the “UEME security capability” sent in the initial message. The
same applies to the GSM ciphering capability if it was included in the RRC Connection
Establishment.MS classmark 2. The MS computes XMAC-I on the message received by using the
indicated UIA, the stored COUNT-I and the received FRESH parameter. The MS verifies the
integrity of the message by comparing the received MAC-I with the generated XMAC-I.

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.

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.

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.

CR page 5
6.8.4 Intersystem handover for CS Services – from UTRAN to
GSM BSS
If ciphering has been started when an intersystem handover occurs from UTRAN to GSM BSS, the
necessary information (e.g. Kc, supported/allowed GSM ciphering algorithms) is transmitted within the
system infrastructure before the actual handover is executed to enable the communication to proceed from
the old RNC to the new GSM BSS, and to continue the communication in ciphered mode. The RNC may
request the MS to send the MS Classmarks 2 and 3 which include information on the GSM ciphering
algorithm capabilities of the MS. This is necessary only if the MS Classmarks 2 and 3 were not transmitted
from UE to UTRAN during the RRC Connection Establishment.The intersystem handover will imply a
change of ciphering algorithm from a UEA to a GSM A5. The GSM BSS includes the selected GSM
ciphering mode in the handover command message sent to the MS via the RNC.

The integrity protection of signalling messages is stopped at handover to GSM BSS.

The START values (see subclause 6.4.8) shall be stored in the ME/USIM at handover to GSM BSS.

CR page 6