Technical Specification Group Services and System Aspects	S3-99348
Meeting #5, 	

TSG SA WG3 #6, Sophia Antipolis, 29 September – 1 October,  1999	
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	017	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	X	UTRAN	X	Core Network	X	
(at least one should be marked with an X)	
	
Source:	S3	Date: 	99-10-09	
	
Subject:	Authentication management field	
	
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:
	An extra parameter, called the authentication management field (AMF), is added to the authentication token (AUTN) in the user authentication request message. A new informative annex is added which gives examples of how AMF may be used. The use of a MODE parameter for sequence number management across CS/PS domains is moved to the new informative annex as an example use of AMF.	
	
Clauses affected:	6.3.2, 6.3.3, 6.3.4, 6.3.5, new Annex F	
	
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:	The abbreviation AMF should be listed in section 3.3.
Figures after number 9 need to be renumbered across the whole document because this CR deletes Figure 10.
A new annex F is inserted before the current annex F (change history).	

6.3.2	Distribution of authentication data from HE to SN
The purpose of this procedure is to provide the SN/VLR with an array of fresh authentication vectors from the user’s HE to perform a number of user authentications.

Figure 5: Distribution of authentication data from HE to SN/VLR
The SN/VLR invokes the procedures by requesting authentication vectors to the HE/AuC. 
The authentication data request shall include a user identity. If the user is known in the SN/VLR by means of the IMUI, the authentication data request shall include the IMUI. However, if the user is identified by means of an encrypted permanent identity (see 6.2), the HLR-message from which the HE can derive the IMUI is included instead. In that case, this procedure and the procedure user identity request to the HLR are integrated. 
Upon the receipt of the authentication data request from the SN/VLR, the HE may have pre-computed the required number of authentication vectors and retrieve them from the HLR database or may compute them on demand. The HE/AuC sends an authentication response back to the SN/VLR that contains an ordered array of n authentication vectors AV(1..n).
Figure 6 shows the generation of an authentication vector AV by the HE/AuC.

Figure 6: Generation of an authentication vector
The HE/AuC starts with generating a fresh sequence number SQN and an unpredictable challenge RAND. 
For each user the HE/AuC keeps track of a counter: SQNHE. 
To generate a fresh sequence number, the counter is incremented and subsequently the SQN is set to the new counter value. 
Note 1:	The HE has some flexibility in the management of sequence numbers. Annex C  and Annex F.3 contain alternative methods for the generation and verification of sequence numbers. 
An authentication and key management field AMF is included in the authentication token of each authentication vector. Example uses of this field are included in Annex F.
Subsequently the following values are computed: 
-	a message authentication code MAC = f1K(SQN || RAND || AMF) where f1 is a message authentication function;
-	an expected response XRES = f2K (RAND) where f2 is a (possibly truncated) message authentication function;
-	a cipher key CK = f3K (RAND) where f3 is a key generating function;
-	an integrity key IK = f4K (RAND) where f4 is a key generating function;
-	an anonymity key AK = f5K (RAND)  where f5 is a key generating function.
Finally the authentication token AUTN =  SQN Å AK || AMF || MAC is constructed. 
Here, AK is an anonymity key used to conceal the sequence number as the latter may expose the identity and location of the user. The concealment of the sequence number is to protect against passive attacks only. 
Note 1:	The need for f5 to use a long-term key different from K is ffs.
Note 2:	The requirements on f3, f4 and f5 are ffs. 
Note 3:	It is also ffs in how far the functions f1, ..., f5 need to differ and how they may be suitably combined. 
6.3.3	Authentication and key agreement 
The purpose of this procedure is to authenticate the user and establish a new pair of cipher and integrity keys between the SN/VLR and the MS. During the authentication, the user verifies the freshness of the authentication vector that is used.

Figure 7: Authentication and key establishment
The SN/VLR invokes the procedure by selecting the next unused authentication vector from the ordered array of authentication vectors in the VLR database.  The SN/VLR sends to the user the random challenge RAND and an authentication token for network authentication AUTN from the selected authentication vector.
Upon receipt the user proceeds as shown in Figure 8. 

Figure 8: User authentication function in the USIM
Upon receipt of RAND and AUTN the user first computes the anonymity key AK = f5K (RAND) and retrieves the sequence number SQN = (SQN Å AK) Å AK. 
Next the user computes XMAC = f1K (SQN || RAND || AMF) and compares this with MAC which is included in AUTN. If they are different, the user sends user authentication reject back to the SN/VLR with an indication of the cause and the user abandons the procedure.
Next the user verifies that the received sequence number SQN is in the correct range.
The USIM keeps track of a counter: SQNMS. 
To verify that the sequence number SQN is in the correct range, the USIM compares SQN with SQNMS. If SQN > SQNMS the MS considers the sequence number to be in the correct range and subsequently sets SQNMS to SQN.
Note:	The MS and the HE have some flexibility in the management of sequence numbers. Annex C and Annex F.3 contain alternative methods for the generation and verification of sequence numbers.
If the user considers the sequence number to be not in the correct range, he sends synchronisation failure back to the SN/VLR including an appropriate parameter, and abandons the procedure.
The synchronisation failure message contains the parameter RANDMS || AUTS. 
Here RANDMS is the random value stored on the MS which was received in user authentication request causing the last update of SQNMS . 
It is AUTS  = Conc(SQNMS ) || MACS.
Conc(SQNMS) = SQNMS  f5K(RANDMS) is the concealed value of the counter SQNMS in the MS, and. 
MACS = f1*K(SQNMS || RAND || AMF) where RAND is the random value received in the current user authentication request. 
f1* is a message authentication code (MAC) function with the property that no valuable information can be inferred from the function values of f1* about those of f1, ... , f5 and vice versa. 
The AMF used to calculate MACS assumes a dummy value of all zeros so that it does not need to be transmitted in the clear in the re-synch message.
The construction of the parameter AUTS in shown in the following Figure 9:

Figure 9: Construction of the parameter AUTS
If the sequence number is considered to be in the correct range however, the user computes RES = f2K (RAND) and includes this parameter in a user authentication response back to the SN/VLR. Finally the user computes the cipher key CK = f3K (RAND) and the integrity key IK = f4K (RAND). Note that if this is more efficient, RES, CK and IK could also be computed earlier at any time after receiving RAND. The MS stores RAND for re-synchronisation purposes.
Upon receipt of user authentication response the SN/VLR compares RES with the expected response XRES from the selected authentication vector. If XRES equals RES then the authentication of the user has passed. The SN/VLR also selects the appropriate cipher key CK and integrity key IK from the selected authentication vector.
Conditions on the use of authentication information by the SN/VLR: Using the procedures described in subsections 6.3.1, 6.3.2 and 6.3.4, authentication vectors will have to be used in the specific order in which they were generated, otherwise the user will reject the authentication attempt. The SN/VLR shall use an authentication vector only once and, hence, shall send out each user authentication request RAND || AUTN only once no matter whether the authentication attempt was successful or not. A consequence is that authentication vectors cannot be reused. When a user changes from one VLR to another one and the new VLR requests remaining authentication vectors from the old VLR (cf. subsection 6.3.4) then the old VLR shall not retain any copies of these authentication vectors. When a VLR receives a “cancel location” request for a certain user it shall delete all authentication vectors relating to that user.  When a VLR receives a location update request from a user and the VLR notices that authentication vectors relating to that user are still stored in the VLR it will delete this information and request fresh authentication vectors from the HE/AuC.
Different rules may apply when one of the alternative schemes for sequence number handling described in Annex C or Annex F.3 are applied. This is true in particular when the schemes based on windows or lists described in Annexes C.3 and C.4 are applied.
6.3.3	Distribution of authentication vectors between VLRs
The purpose of this procedure is to provide a newly visited VLR with unused authentication vectors from a previously visited VLR. The procedure is shown in Figure 10.

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. Upon receipt of the request the VLRo verifies whether it has any unused authentication vectors of the appropriate mode in its database and if so, sends the unused authentication vectors to VLRn. The previously visited VLRo shall then delete these authentication vectors from its database.
Upon receipt the VLRn stores the received authentication vectors. 
If VLRo indicates that it has no authentication vectors or the VLRo cannot be contacted, VLRn should request new authentication vectors from the user’s HE using the procedure described in 6.3.2.

6.3.5	Re-synchronisation procedure
An SN/VLR may send two types of authentication data requests to the HE/AuC, the (regular) one described in subsection 6.3.2 and one used in case of synchronisation failures, described in this subsection. 
Upon receiving a synchronisation failure message from the user, the SN/VLR sends an authentication data request with a “synchronisation failure indication” to the HE/AuC, together with the parameters
-	RAND sent to the MS in the preceding user authentication request and 
-	RANDMS || AUTS received by the SN/VLR in the response to that request, as described in subsection 6.3.3. 
An SN/VLR will not react to unsolicited “ synchronisation failure indication” messages from the MS.
The SN/VLR does not send new user authentication requests to the user before having received the response to its authentication data request from the HE/AuC (or before it is timed out).
When the HE/AuC receives an authentication data request with a “synchronisation failure indication” it acts as follows: The HE/AuC verifies AUTS by computing f5K(RANDMS), retrieving SQNMS from Conc(SQNMS) and verifying MACS (cf. subsection 6.3.3.). If the verification is successful, but SQNMS is such that SQNHE is not in the correct range then the HE/AuC resets the value of the counter SQNHE to SQNMS.
Otherwise, the HE/AuC leaves SQNHE unchanged. 
In all cases the HE/AuC sends an authentication data response with a new batch of authentication vectors to the SN/VLR. If the counter SQNHE was not reset then these authentication vectors can be taken from storage, otherwise they are newly generated after resetting SQNHE. In order to reduce the real-time computation burden on the HE/AuC, the HE/AuC may also send only a single authentication vector in the latter case.
Whenever the SN/VLR receives a new batch of authentication vectors from the HE/AuC in an authentication data response it deletes the old ones for that user in the VLR. 
The user may now be authenticated based on a new authentication vector from the HE/AuC.
 Optionally, in order to minimise extra effort by the HE/AuC, in an authentication data request with synchronisation failure indication the SN/VLR may also send the concealed sequence number Conc(SQNSN) corresponding to the last authentication vector received which the SN/VLR has in storage, i.e. it may send Conc(SQNSN) = RANDSN || SQNSNf5K(RANDMS). 
On receipt the HE/AuC retrieves SQNSN from Conc(SQNSN). If the counter in the HE/AuC did not have to be reset and if SQNSN = SQNHE the HE/AuC informs the SN/VLR accordingly and does not send fresh authentication vectors. (In this way, a synchronisation failure does not cause the HE/AuC to produce extra authentication vectors when they are not needed.)
Figure 12 shows how re-synchronisation is achieved by combining a user authentication request answered by a synchronisation failure message (as described in subclause 6.3.3) with an authentication data request with synchronisation failure indication answered by an authentication data response (as described in this subclause).

HE

SN

MS

User auth request (RAND || AUTN)

Auth data  request (id,), 
 synch failure ind (RAND || RANDMS || AUTS)

synch failure (RANDMS || AUTS)

Auth data response (auth vectors)

Figure 12: Re-synchronisation procedure
Annex F (Informative): Example uses of AMF
F.1	Support multiple authentication algorithms and keys
A mechanism to support the use of multiple authentication and key agreement algorithms is useful for disaster recovery purposes. AMF may be used to indicate the algorithm and key used to generate a particular authentication vector.
The USIM keeps track of the authentication algorithm and key identifier and updates it according to the received value.
F.2 	Changing the size of windows and lists
This mechanisms is used in conjunction with the window and list mechanisms described in Annexes C.3 and C.4.
A mechanism to change the window and list size dynamically is useful since the optimum window and list size may change over time. AMF is used to indicate the maximum admissible window or list size to be used by the user when verifying the authentication token. 
The USIM keeps track of the window or list size and updates it according to the received value providing that SQN > SQNMS. 
F.3	Handling authentication vectors from separate CS/PS domains using a MODE parameter 
A mechanism to distinguish authentication vectors from different CS/PS domains is useful so that separate CS/PS nodes can simultaneously and independently support mobility management for the user. AMF is used to indicate the domain associated with a particular authentication vector. Using this mechanism two counters are required for each domain in both the USIM and the AuC.
Note:	If a single counter was used, the following problem occurs: Suppose that a CS node orders SQNs 1–5, and uses SQN 1 and then a PS node orders SQNs 6–10 and uses 6. At this point the CS node may need to use SQN 2, but cannot since the SQN will be rejected and must order new authentication vectors, with SQNs 11–15, and authenticates with SQN 11. Maintaining separate counters for CS and PS domains provide a solution for this problem.
An alternative to the use of the MODE parameter is the use of the window or list mechanism described in Annexes C3. and C.4.