TSG SA WG3 #7, The Hague, 26th October – 27th October 1999						S3-99269
	
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	X	Current Version:	V3.1.0		
					
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		ME		UTRAN		Core Network	x	
(at least one should be marked with an X)	
	
Source:	S3	Date: 	19-10-99	
	
Subject:	Distribution of Authentication vectors between VLRs/SGSNs  	
	
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:
	For a UMTS user (USIM), the triplets derived from quintuplets can only be used in GSM security context since for a UMTS security context the needed quintuplet would be derived in the VLR/SGSN from the already derived triplet, obtaining as a result a non-real quintuplet. That non-real quintuplet would provoke an authentication error because the UMTS user would be using a real quintuplet in the MS.
Consequently the behaviour in the VLR/SGSN nodes should be different depending on the triplet origin.
The distribution of authentication vector between SGSNs is also included in the corresponding chapter.	
	
Clauses affected:	Sections 6.3.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.4	Distribution of authentication vectors between VLRs and between SGSNs
The purpose of this procedure is to provide a newly visited VLR or SGSN with unused authentication vectors from a previously visited VLR or SGSN. Note: this relates to the exchange of vectors between core network nodes of the same domain type, i.e. between VLRs and SGSNs. The procedure is shown in Figure 10.

Figure Figure 10: Distribution of authentication vectors between VLRs
The procedure is initiated by the visited VLR and illustrated in the following Figure 11: 

Figure 11: Distribution of authentication data between SN/VLR
The procedure is invoked by the newly visited SN/VLRn after a location update request sent by the user. Typically the user identifies himself using a temporary user identity TMUIo and the location area identity LAIo of a location area under the jurisdiction of SN/VLRo. In that case this procedure is integrated with the procedure described in 6.1.4.
With regards to the PS domain, this procedure is invoked by the newly visited SGSN after a routing area update is sent by the user. The user identifies himself using a temporary user identity P-TMSI and the routing area identity RAIo of a routing area under the jurisdiction of the old SGSN.
Upon receipt of the request the VLRo or SGSN verifies whether it has any unused authentication vectors of the appropriate mode in its database and if so, sends the unused authentication vectors to the VLRn or new SGSN respectively. The previously visited VLRo or SGSN shall then delete these authentication vectors from its database.
Upon receipt of the response from an UMTS capable SN/VLR or SGSN the  new CN node stores the received authentication vectors. 
Upon receipt of the response from a non-UMTS capable SN/VLR or SGSN the new CN node can use the received authentication vectors only in GSM security context and shall not send those authentication vectors to any UMTS capable SN/VLR or SGSN.
If VLRo or the old SGSN indicates that it has no authentication vectors or the CN node cannot be contacted, the VLRn or SGSN should request new authentication vectors from the user’s HE using the procedure described in 6.3.2.