TSG SA WG3 #6, Sophia Antipolis, 29 Sep – 1 Oct, 1999-10-01							S3-99350
	
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	019	Current Version:	V3.1.0		
					
3G specification number 		 CR number as allocated by 3G support team	
	
For submission to TSG	SA#5	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		UTRAN		Core Network	x	
(at least one should be marked with an X)	
	
Source:	3GPP TSG SA WG 3 	Date: 	01-10-99	
	
Subject:	Modification of text for window and list mechanisms 	
	
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					
with an X)	D	Editorial modification	x				
	
Reason for 
change:
	The current text in Annexes C.3 and C.4 contains inaccuracies which are clarified in this change request. In addition, the editorial effects of CRs 017 and 019 agreed by 3GPP TSG SA WG 3 are taken into account.

Clauses affected:	Annex C.3, Annex C.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:		

  <--------- double-click here for help and instructions on how to create a CR. 

C.3	A mechanism using one individual counter in the HE and a window in the USIM
In this mechanism the sequence numbers are generated as in the mechanism described in C.1. However, the USIM verifies the freshness differently. In addition to the highest sequence number SQNMS it has accepted, it keeps track of which values in a window  [SQNMS – w, SQNMS) it has already accepted... If a sequence number is received that is higher than SQNMS – w  and has not been accepted before, it is accepted and the window is updated accordingly. 
Using this mechanism, it is not required that a previously visited SN/VLR deletes the unused authentication vectors when a user de-registers from the serving network. Retaining the authentication vectors for use when the user returns later may be more efficient as regards signalling when a user abroad switches a lot between two serving networks.
Note:	When a VLR uses fresh authentication vectors obtained during a previous visit of the user, the USIM can reject them although they have not been used before (because w is finite). Rejection of a sequence number can therefore occur in normal operation, i.e., it is not necessarily caused by (malicious) replay or a database failure. 

C.4	A mechanism using a (partly) global counter in the HE and a list in the USIM
In this mechanism the sequence numbers are generated with one of the mechanisms described in C.2 and in C.6. However, the USIM verifies the freshness differently. Instead of keeping track of the highest sequence number SQNMS only, it keeps track of an ordered list of the b highest values it has accepted,. If a sequence number is received that is lower than or equal to the lowest value SQNLO in that list, it is rejected. If however, a sequence number is received that is higher than the lowest entry in the list, but is not in the list it is accepted and included in the list. The lowest value SQNLO in the list is then deleted.
Using this mechanism, it is not required that a previously visited SN/VLR deletes the unused authentication vectors when a user de-registers from the serving network. Retaining the authentication vectors for use when the user returns later may be more efficient as regards signalling when a user abroad switches a lot between two serving networks.
Note:	When a VLR uses fresh authentication vectors obtained during a previous visit of the user, the USIM can reject them although they have not been used before (because b is finite). Rejection of a sequence number can therefore occur in normal operation, i.e., it is not necessarily caused by (malicious) replay or a database failure.