Technical Specification Group Services and System Aspects	S3-99524
Meeting #9, Helsinki, 7- 9 December 1999
	
DRAFT 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.105	CR	006	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	X	Core Network		
(at least one should be marked with an X)	
	
Source:	TSG SA WG3	Date: 	08-12-99	
	
Subject:	Authentication and key agreement algorithms	
	
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:	Align with TS33.103 (Security Architecture), descriptions and figures on the authentication and key agreement algorithms have been modified.	
	
Clauses affected:	5.1	
	
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:		

5.1	
Authentication and key agreement
5.1.1	Overview
The mechanism for authentication and key agreement described in clause 6.3 of [1] requires the following cryptographic functions:
f0	the random challenge generating function;
f1	the network authentication function;
f1*	the re-synchronisation message authentication function;
f2	the user authentication function;
f3	the cipher key derivation function;
f4	the integrity key derivation function;
f5	the anonymity key derivation function.

Figure 1 illustrates the use of the cryptographic functions f0—f5 at the HE/AuC.

Figure 1: Functions for authentications and key agreement in the HE/AuC
The input parameters to the algorithms are the long-term secret Key (K), the Sequence Number (SQN), a random challenge (RAND) generated by f0 and an authentication and key management field (AMF). Based on K and RAND f2—f5 compute an expected RESponse (XRES), a Cipher Key (CK), an Integrity Key (IK) and an Anonymity Key (AK) which is bitwise XOR-ed with SQN. Based on K, RAND, SQN and AMF, f1 derives a Message Authentication Code for network to user Authentication (MAC-A). 
Figure 2 illustrates the use of function f1* and f5 in the AuC .
The input parameters to the algorithm f1* are the long-term secret Key (K), the Sequence Number (SQNMS), a random challenge (RAND) received by the AuC from the SN and an authentication and key agreement field (AMF). Based on these input parameters, a message authentication code MAC-S on the synchronisation failure data is computed. The input parameters to the algorithm f5 are the long-term secret Key (K) and the message authentication code MAC-S. Based on these input parameters, an anonymity key (AK) is computed.

Figure 2: The re-synchronisation message authentication function in the AuC

Figure 3 illustrates the use of the cryptographic functions f1—f5 in the USIM.

Figure 3: Functions for authentication and key agreement in the USIM
This time the Anonymity Key (AK) has to be computed in advance to retrieve SQN from SQN  AK. From there on, f1 is used to derive XMAC-A from K, RAND, SQN and AMF and f2—f4 are used to derive RES, CK and IK in the same way as the AuC derived MAC-A, XRES, CK and IK. 
The use of the function in f1*  in the USIM is strictly analogous to that in the AuC. A figure is therefore omitted. Based on the input parameters long-term secret Key (K), Sequence Number (SQN), random challenge (RAND) received by the USIM from the SN and authentication and key agreement field (AMF), a message authentication code MAC-S on synchronisation failure data is computed.
Note:	An alternative mechanism for authentication and key agreement that requires a different set of cryptographic functions is included in Annex D of [1]. The requirements on the cryptographic functions required for that mechanism are described in Annex A of this specification.
5.1.2		Use
The functions f0—f5 shall only be used to provide mutual entity authentication between USIM and AuC, derive keys to protect user and signalling data transmitted over the radio access link and conceal the sequence number to protect user identity confidentiality. The function f1* shall only be used to provide data origin authentication for the synchronisation failure information sent by the USIM to the AuC.
5.1.3	Allocation 
The functions f1—f5 and f1*are allocated to the Authentication Centre (AuC) and the USIM. The function f0 is allocated to the AuC.
5.1.4	Extent of standardisation
The functions f0—f5 and f1*are proprietary to the home environment. Examples of the functions f1, f1* and f2 are CBC-MACs or H-MACs [3].
5.1.5	Implementation and operational considerations
The functions f1—f5 and f1* shall be designed so that they can be implemented on an IC card equipped with a X1-bit microprocessor running at X2 MHz with X3 kbits of memory and produce AK, MAC-A and RES in less than X4 ms, and CK and IK in less than X5 ms.
The functions f0—f5 and f1* shall be designed so that they can be implemented either in software or in hardware in the AuC on a X6-bit microprocessor running at X7 MHz and with X8 kbits of memory and produce MAC-A, XRES, CK, IK and AK in less than X9 ms.
5.1.6	Type of algorithm
Note 1: Note: Requirements on f3, f4 and f5 are ffs.
Note 2: How f1-f5 can be made different and how they may be suitably combined is ffs
5.1.6.1	f0
f0: the random challenge generating function
f0: 		(internal state)  RAND
f0 should be (pseudo) random number generating function. 
5.1.6.2	f1
f1: the network authentication function
f1: 		(K; SQN, RAND, AMF)  MAC-A (or XMAC-A)
f1 should be a MAC function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND, SQN, AMF and MAC-A (or XMAC-A). 
5.1.6.3	f1*
f1*: the re-synchronisation message authentication function
f1*:	(K; SQN, RAND, AMF)  MAC-S (or XMAC-S)
f1 should be a MAC function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND, SQN, AMF and MAC-S (or XMAC-S).
5.1.6.4	f2
f2: the user authentication function 
f2: 		(K; RAND)  RES (or XRES)
f2 should be a MAC function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND and RES (or XRES).
5.1.6.5	f3
f3: the cipher key derivation function 
f3: 		(K; RAND)  CK
f3 should be a key derivation function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND and CK.
5.1.6.6	f4
f4: the integrity key derivation function 
f4: 		(K; RAND)  IK
f4 should be a key derivation function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND and IK.
5.1.6.7	f5
f5: the anonymity key derivation function 
As part of the authentication procedure f5 is used to generate the anonymity key as follows:
f5: 		(K; RAND)  AK
f5 should be a key derivation function. In particular, it shall be computationally infeasible to derive K from knowledge of RAND and AK.
As part of the re-syncrhonisation procedure f5 is used to generate the anonymity key as follows:
f5: 		(K; MAC-S)  AK
f5 should be a key derivation function. In particular, it shall be computationally infeasible to derive K from knowledge of MAC-S and AK.
Note1: If no concealment is required then f50. 
Note2: Crypto requirements on f5 when used in the re-syncrhonisation procedure are higher because an attacker can make the MS produce different AK using the same SQNms. In addition, the concatenation of f5 and f1* should not reveal anything about SQNms.
Note 3: For f5 to use long term key different to K is ffs5.1.7	Operator variant key
It is desirable that the algorithm support an operator variant key such that the algorithm may be modified in a controlled manner which does not affect cryptographic strength.
5.1.8	Interface
5.1.8.1	K
K: the user authentication key
K[0], K[1], …, K[127]
The length of K is 128 bits. The user authentication key K is a long term secret key stored in the USIM and the AuC.
5.1.8.2	RAND
RAND: the random challenge
RAND[0], RAND[1], …, RAND[127]
The length of RAND is 128 bits. 
5.1.8.3	SQN (or SQNMS)
SQN: the sequence number
SQN[0], SQN[1], …, SQN[X10-1]
The length of SQN is between 48 bits. The AuC should include a fresh sequence number in each authentication token. The verification of the freshness of the sequence number by the USIM constitutes to entity authentication of the network to the user. 
5.1.8.4	AMF
AMF: the authentication and key agreement field
AMF[0], AMF[1], …, AMF[15]

The length of AMF is 16 bits. AMF is included in the authentication token of each authentication vector.
5.1.8.6	MAC-A (equivalent for XMAC-A)
MAC-A: the message authentication code used for authentication of the network to the user
MAC-A[0], MAC-A[1], …, MAC-A[63]
The length of MAC-A is 64 bits. MAC-A authenticates the data integrity and the data origin of RAND, SQN and MODE. The verification of MAC-A by the USIM constitutes to entity authentication of the network to the user.
5.1.8.7	MAC-S (equivalent for XMAC-S)
MAC-S: the message authentication code used to provide data origin authentication for the synchronisation failure information sent by the USIM to the AuC.
MAC-S[0], MAC-S[1], …, MAC-S[63]
The length of MAC-S is 64 bits. MAC-S authenticates the data integrity and the data origin of RAND, SQN and MODE. MAC-S is generated by the USIM and verified by the AuC.
5.1.8.8	RES (or XRES)
RES: the user response 
RES[0], RES[1], …, RES[X21]
or XRES: the expected user response
XRES[0], XRES[1], …, XRES[X21]
The maximum length of RES and XRES is 128 bits and the minimum is 32 bits. RES and XRES constitute to entity authentication of the user to the network.
5.1.8.9	CK
CK: the cipher key 
CK[0], CK[1], …, CK[127]
The length of CK is 128 bits. In case the effective key length should need to be made smaller than 128 bits, the most significant bits of CK shall carry the effective key information, whereas the remaining, least significant bits shall be set zero.
5.1.8.10	IK
IK: the integrity key
IK[0], IK[1], …, IK[127]
The length of IK is 128 bits. In case the effective key length should need to be made smaller than 128 bits, the most significant bits of IK shall carry the effective key information, whereas the remaining, least significant bits shall be set zero.
5.1.8.11	AK
AK: the anonymity key
AK[0], AK[1], …, AK[X10-1]
The length of AK is 48 bits. It equals the length of SQN.
5.1.8.11	Operator variant key
To be defined.