TSG-SA WG3 (Security) meeting #6	TSGS-WG3#6(99)302
Sophia Antipolis, 29 September – 1 October, 1999	

Agenda Item:	9.2
Source:	Vodafone / Joint session on the USIM at T3#8
Title:	Support for multiple authentication algorithms and keys
Document for:	Discussion/Decision
___________________________________________________________________________
1.	Introduction
An LS was sent from T3 to S3 on multiple authentication algorithms and keys (S3-99212). It requests S3 feedback on whether provisions should be made to allow for multiple authentication algorithms and/or multiple authentication keys within a USIM. 
In a reply (S3-99259) S3 states that an explicit feature to support multiple algorithm algorithms and/or keys would be useful and explains that S3 are now planning to produce a mechanism to support this feature.
This item was discussed at the joint session on the USIM at T3#8 on 24 August. A number of possible mechanisms were discussed. However, it was agreed that S3 should investigate one particular mechanism. This proposal is based on that mechanism.
2.	Proposal
It is proposed to add an extra parameter, called the algorithm and key identifier (AID), to the authentication token (AUTN) in the user authentication request message. This parameter may then be used by the operator to indicate which algorithm and key should be used in the current authentication and key agreement protocol run. The extra parameter would be integrity protected by including it as an input in the calculation of the MAC parameter contained in AUTN. One of the reasons for integrity protecting AID is to help guard against attacks on “spare” algorithms and keys.
AID should be variable length with the upper and lower bounds being standardised (the lower bound could be one bit). The exact format and use of AID should be operator dependant. However, a recommended solution may be included in an informative annex.
An example use of AID would be to use it to transport an explicit indicator to the USIM during algorithm and/or key changeover. Outside this period an explicit indicator would not need to be sent. The USIM could store the last correctly verified AID as the current default to be used if an explicit indication is not given. This implicit indication would help save on bandwidth, storage and processing costs. The fact that AID is integrity protection should help to guard against denial of service attacks in this case were the attacker attempts to change the default algorithm and key on the USIM.
It is for further study whether AID also needs to be added the authentication token AUTS in the synchronisation failure message returned by the user in the event that the sequence number SEQ in the authentication token AUTN is not accepted. 
3.	Conclusions
S3 is asked to investigate the suitability of this mechanism, including whether there are any security problems. If deemed acceptable then the necessary CR to 33.102 should be developed. It is also necessary to ensure that the changes are reflected in the latest draft of 33.103 which should be approved and then sent to T3 in good time for T3#9.