TSG SA WG3 #7,																							S3-99370
	
3G CHANGE REQUEST	Please see embedded help file at the bottom of this
page for instructions on how to fill in this form correctly.	
	
	TS 33.102	CR	xx	Current Version:	V3.x.x		
					
3G specification number 		 CR number as allocated by 3G support team	
	
For submission to TSG	SA#7	for approval	x	(only one box should	
list TSG meeting no. here 	for information		Be marked with an X)	
	
Form: 3G CR cover sheet, version 1.0        The latest version of this form is available from: ftp://ftp.3gpp.org/Information/3GCRF-xx.rtf	
	
Proposed change affects:	USIM	x	ME	x	UTRAN		Core Network	x	
(at least one should be marked with an X)	
	
Source:	S3	Date: 	12-10-99	
	
Subject:	Secure UMTS-GSM Interoperation  	
	
3G Work item:	Security	
	
Category: 	F	Correction					
	A	Corresponds to a correction in a 2G specification					
(only one category 	B	Addition of feature					
shall be marked	C	Functional modification of feature	x				
with an X)	D	Editorial modification					
	
Reason for 
change:
	This proposal updates the previous change request S3-99332 to include references to the Packet Switched Core Network.	
	
Clauses affected:	Sections 6.3.7, 6.4.8.1 , 6.6.9.4	
	
Other specs	Other 3G core specifications		  List of CRs:		
affected:	Other 2G core specifications		  List of CRs:		
	MS test specifications		  List of CRs:		
	BSS test specifications		  List of CRs:		
	O&M specifications		  List of CRs:		
	
Other 
comments:		

6.3.7	Interoperability with 2G networks
6.3.7.1	Interoperability for UMTS users
A general principle in designing the security interoperation between 3G and 2G networks has been that a UMTS user (i.e. a user with a USIM issued by a R99 HLR/AuC) shall get UMTS level of security whenever possible. 
The mechanism described here achieves intersystem operability between UMTS and GSM/GPRS networks allowing secure interoperation between both networks for UMTS users (USIM). The following figure illustrates the different scenarios of interoperability for UMTS users:

UMTS
HLR/AuC

UMTS
MSC/VLR or SGSN

GSM 
MSC/VLR or SGSN
Non-UMTS capable

UMTS Access Network

UMTS AV
(RAND, XRES, CK, IK, AUTN)

GSM Data
(RAND,  Kc)

UMTS Data
(RAND, CK, IK, AUTN)

GSM Data
(RAND,  Kc)

GSM AV
(RAND, SRES, Kc)

GSM 
MSC/VLR or SGSN
UMTS capable

GSM Data
(RAND,  Kc)

UMTS AV
(RAND, XRES, CK, IK, AUTN)

GSM
Access Network

GSM
Access Network

GSM
Access Network

Or UMTS Data
(RAND, CK, IK, AUTN)

Or UMTS Data
(RAND, CK, IK, AUTN)

Figure 13: Interoperability for UMTS Users
The UMTS authentication parameters are generated by the UMTS HLR/AuC and USIM by use of the home operator specified algorithms for this purpose.
Upon receipt of an authentication data request from a UMTS SN/VLR or a UMTS capable GSM SN/VLR, the HLR/AuC sends an ordered array of n UMTS authentication vectors (quintuplets) to the SN/VLR.  Similarly, upon receipt of an authentication data request from a UMTS SGSN or UMTS capable GPRS SGSN, the HLR/Auc sends an ordered array of n UMTS authentication vectors (quintuplets) to the SGSN.
If the UMTS MSC/VLR or SGSN is able to handle GSM radio access network, the MSC/VLR or SGSN shall be able to derive a GSM authentication vector from the received UMTS vector, by means of the standardised conversion functions defined below, in order to provide the GSM security parameters to the GSM radio access network. Whether GSM Data or UMTS Data is used depends on the terminal capabilities.
Upon receipt of an authentication data request from a non-UMTS capable GSM SN/VLR or SGSN, the HLR/AuC shall derive the GSM authentication vectors from the UMTS vectors, by means of the standardised conversion functions defined below. Then, the HLR/AuC sends an authentication response back to the SN/VLR or SGSN that contains an ordered array of n GSM authentication vectors (triplets). The HLR/AuC may have pre-computed GSM authentication vectors or may derive them on demand from the UMTS authentication vectors.
On the mobile side, the USIM shall derive the GSM authentication parameters from the UMTS authentication parameters by means of the standardised conversion functions, when the MS is located in the GSM radio access network.
The previous procedures are also applicable to the corresponding PS network and so as to the corresponding SGSN entity.
Subsequently the following entities shall implement the standardised conversion functions for generating GSM authentication vectors (triplets) from UMTS authentication vectors (quintuplets):
•	UMTS HLR/AuC
•	UMTS MSC/VLR 
•	UMTS SGSN
•	UMTS capable GSM MSC/VLR
•	UMTS capable GSM SGSN
•	USIM
Interoperability with non-UMTS capable GSM entities is achieved by use of the standardised conversion functions implemented in the HLR/AuC. The handover case is described in sections 6.4.8.1 and  6.6.9.4.
The following conversion functions shall be computed for generating the GSM authentication parameters:
•	Generation of GSM RAND
f: (RANDU) -> RANDG;  		RANDG = RANDU

•	Generation of GSM SRES
f: (XRES) -> SRES;  			SRES =XRES1  XRES2  XRES3  XRES4
whereby XRES = XRES1 || XRES2 || XRES3 || XRES4; and with XRESn 32 bits each. If any of XRESn is not used, it is assumed zeros. 

•	Generation of GSM Kc
f: (CK, IK) -> Kc;  				Kc = CK1  CK2  IK1  IK2 
whereby CK1 (resp. IK1) is the first half and CK2 (resp. IK2) is the second half of CK (resp. IK)

The GSM authentication vector is generated using the UMTS authentication parameters. Consequently, the generated triplet depends on the UMTS authentication algorithms and inputs parameters for these algorithms, all this information under the control of the HE, being the algorithms operator specific.
The GSM authentication and key generating algorithms are specified as follows:
A3: RANDG -> SRES;			SRES = f(f2K(RANDU))
A8: RANDG -> Kc;				Kc = f(f3K(RANDU), f4K(RANDU))

6.3.7.2	Interoperability for GSM users
The mechanism described here achieves intersystem operability between UMTS and GSM networks allowing secure interoperation between both networks for GSM users (SIM). The following figure illustrates the different scenarios of interoperability for 2G users:

GSM
HLR/AuC

UMTS
MSC/VLR or SGSN

GSM 
MSC/VLR or SGSN
Non-UMTS capable

UMTS Access Network

GSM AV
(RAND, SRES, Kc)

GSM Data
(RAND,  Kc)

UMTS Data
(RAND, CK, IK)

GSM Data
(RAND,  Kc)

GSM AV
(RAND, SRES, Kc)

GSM 
MSC/VLR or SGSN
UMTS capable

GSM Data
(RAND,  Kc)

GSM AV
(RAND, SRES, Kc)

GSM
Access Network

GSM
Access Network

GSM
Access Network

Figure 14: Interoperability for GSM Users
The GSM authentication parameters are generated by the GSM HLR/AuC and the SIM by use of the home operator specified algorithms for this purpose.
Upon receipt of an authentication data request from any SN/VLR or SGSN (UMTS or GSM), the HLR/AuC sends an ordered array of n GSM authentication vectors (triplets) to the SN/VLR.
If the UMTS MSC/VLR or SGSN is able to handle UMTS radio access network, the MSC/VLR or SGSN shall be able to derive a UMTS authentication vector from the received GSM authentication vector, by means of the standardised conversion functions defined below, in order to provide the UMTS security parameters to the UMTS radio access network. 
On the mobile side, the UE shall derive the UMTS authentication parameters from the GSM authentication parameters generated by the SIM by means of the standardised conversion functions, when the MS is located in the UMTS radio access network.
The previous procedures are also applicable to the corresponding PS network and so as to the corresponding SGSN entity.
Subsequently the following entities shall implement the standardised conversion functions for generating UMTS authentication parameters from GSM authentication vectors (triplets):
•	UMTS MSC/VLR
•	UMTS SGSN
•	UE
The following conversion functions shall be computed for generating the UMTS authentication parameters:
•	Generation of UMTS RAND
f: (RANDG) -> RANDU;  				RANDU = RANDG
•	Generation of UMTS XRES
f: (SRES) -> XRES;  					XRES = SRES
•	Generation of UMTS CK
f: (Kc) -> CK;  							CK = 0..0 || Kc
•	Generation of UMTS IK
f: (Kc) -> IK;  							IK = Kc || Kc
•	Generation of UMTS AUTN
The authentication token AUTN is not used for GSM users.
The UMTS authentication vector is generated using the GSM authentication parameters. Consequently, the generated quintuplet depends on the GSM authentication algorithms and inputs parameters for these algorithms, all this information under the control of the HE, being the algorithms operator specific.
A GSM user should receive the security level provided by the home network. The effective encryption key length used in UMTS radio access network is the GSM Kc length, provided by the HE; Integrity protection is provided by using the GSM encryption key; and the AUTN parameter is not used.
The UMTS authentication and key generating algorithms are specified as follows:
f2: RANDu -> XRES;						XRES =A3(RANDG)
f3: RANDu -> CK;							CK = 0..0 || A8(RANDG)
f4: RANDu -> IK;								IK = A8(RANDG) || A8(RANDG)
f: (RANDu, SEQ, AK, MAC) -> AUTN;	Parameter not used

6.4.8	Integrity protection procedures
Integrity protection is performed by appending a message authentication code (MAC-I) to the message that is to be integrity protected. The MS can append the MAC-I to signalling messages as soon as it has received a connection specific FRESH value from the RNC.
If the value of HFNMS is larger or equal to the maximum value stored in the USIM, the MS indicates to the network in the RRC connection set-up that it is required to initialise a new authentication and key agreement.
Note:	The precise set-up of data integrity is for further study. 
6.4.8.1	Handover
Note:	It is expected that in case of inter-operator handover a handover agreement exists that covers all charging aspects. Agreements on cipher key transportation/re-use shall also be included.
1)	Intra-system:
	When a handover occurs, the IK is transmitted within the system infrastructure from the old RNC to the new one to enable the communication to proceed, and the synchronisation procedure is resumed. The key IK remains unchanged at handover.  This applies equally both to CS and PS domains.
2)	Inter-system:
UMTS  GSM/GPRS
The GSM network entered by the user handing over from UMTS does not provide integrity protection and the integrity key (IK) is not needed in the GSM network. 
GSM/GPRS  UMTS
The UMTS network entered by the user handing over from GSM will enable integrity protection. This will involve setting the integrity protection key (IK). There are two options:
a)	Handover from a UMTS capable GSM network
Within the CS domain, when handover occurs, the IK is transmitted from the old MSC/VLR to the new one to enable the communication to proceed.
Within the PS domain, the new UMTS SGSN will request the subscribers MM Context from the GPRS SGSN.  The IK is then included in the response to the new SGSN.
b)   Handover from a non-UMTS capable network. The method below is not recommended but presented if it will be a service requirement. There are doubts whether there is a requirement for this kind of handover and whether it is possible on, for instance, the MAP/E interface. 
The UMTS integrity key shall be derived by the UMTS network and UE by using the conversion functions specified in section 6.3.7.2 for this purpose.
Within the CS domain, when handover occurs, the Kc is transmitted from the old MSC/VLR to the new one to enable the communication to proceed. 
Within the PS domain, the new SGSN requests the Kc within an MM Context from the old SGSN.  The Kc is then included in the response to the new SGSN where it is then used to derive an IK in order to enable communication to proceed.
6.6.9	Ciphering procedures
6.6.9.1	Starting of the ciphering and deciphering processes
The MS and the RNC must co-ordinate the instants at which the enciphering and deciphering processes start.
This procedure takes place under the control of the network some time after the completion of the authentication procedure (if any), or after the key CK has been made available at the RNC.
No information elements for which protection is needed must be sent before the ciphering and deciphering processes are operating.
The transition from clear text mode to ciphered mode proceeds as follows: deciphering starts in the RNC, which sends in clear text to the MS a specific message, here called "Start cipher". Both the enciphering and deciphering start on the MS side after the message "Start cipher" has been correctly received by the MS. Finally, enciphering on the RNC side starts as soon as a frame or a message from the MS has been correctly deciphered at the RNC.
[diagram to be added]
6.6.9.2	Synchronisation
The enciphering stream at one end and the deciphering stream at the other end must be synchronised, for the enciphering bit stream and the deciphering bit streams to coincide. 
Synchronisation is guaranteed by driving UEA by an explicit time variable, COUNT, derived from an appropriate frame number available at the MS and at the RNC. 
The diagram below summarises the implementation indications listed above, with only one enciphering/deciphering procedure represented (the second one for deciphering/enciphering is symmetrical).
[diagram to be added]
6.6.9.3	Layer for ciphering
The layer on which ciphering takes place depends on the Layer 2 mode of the data. Data transmitted on logical channels using a non-transparent RLC mode (either Acknowledged Mode or Unacknowledged Mode) is ciphered in the RLC sub-layer of Layer 2. Data transmitted on a logical channel using the transparent RLC mode is ciphered at the MAC sub-layer of Layer 2.
6.6.9.4	Handover
Note:	It is expected that in case of inter-operator handover a handover agreement exists that covers all charging aspects. Agreements on cipher key transportation/re-use shall also be included.
1)	Intra-system
	When a handover occurs, the CK is transmitted within the system infrastructure from the old RNC to the new one to enable the communication to proceed, and the synchronisation procedure is resumed. The key CK remains unchanged at handover. This applies equally both to CS and PS domains.
2)	Inter-system
UMTS  GSM/GPRS
The GSM network entered by the user handing over will enable ciphering protection. This involves setting the GSM cipher key (Kc).
The GSM cipher key shall be derived by the UMTS network by using the conversion functions specified in section 6.3.7.1 for this purpose.
Within the CS domain, when handover occurs, the generated Kc is transmitted from the old MSC/VLR to the new one to enable the communication to proceed.
Within the PS domain, the new GSM SGSN will request the subscribers MM Context from the UMTS SGSN.  The UMTS SGSN will in turn return the required information including the generated Kc.
GSM/GPRS  UMTS
The UMTS network entered by the user handing over from GSM will enable confidentiality protection. This will involve setting the cipher  key (CK). There are two options:
a)	Handover from a UMTS capable GSM network
Within the CS domain, when handover occurs, the CK is transmitted from the old MSC/VLR to the new one to enable the communication to proceed.
Within the PS domain, the new UMTS SGSN will request the subscribers MM Context from the GPRS SGSN.  The CK is then included in the response to the new SGSN.b)	Handover from a non-UMTS capable network. The method below is not recommended but presented if it will be a service requirement. There are doubts whether there is a requirement for this kind of handover and whether it is possible on, for instance, the MAP/E interface
The UMTS cipher key shall be derived by the UMTS network an UE by using the conversion functions specified in section 6.3.7.2 for this purpose.
Within the CS domain, when handover occurs, the Kc is transmitted from the old MSC/VLR to the new one where it is then used to derive a CK in order to enable the communication to proceed.
Within the PS domain, the new UMTS SGSN requests the Kc within an MM Context from the old GPRS SGSN.  The Kc is then included in the response to the new UMTS SGSN where it is then used to derive a CK in order to enable communication to proceed.