Figure
1 : The Entities Involved in the Migration
Process
Group: Network
Abstract: This paper presents the results of work undertaken as part of the European Commission-funded ACTS ASPeCT (Advanced Security for Personal Communication Technologies) project [AC095]. Its objective is three-fold:
(a) to propose a "general framework" for the migration of security offered by second generation systems (GSM, DCS1800, DECT) towards UMTS security,
(b) to investigate the possible security enhancements in the different 'transition phases'
(c) to provide a flexible Authentication Framework which allows a number of different mechanisms and algorithms to be incorporated, along with the ability to migrate smoothly from one mechanism to another.
Currently, work is under way within ETSI to define a third generation mobile telecommunications system, known as the Universal Mobile Telecommunications System (UMTS), to be introduced in the early years of the 21st century. The main objective of UMTS is to offer a plethora of advanced mobile telecommunication services via a variety of public and private network operators in both outdoor and indoor environments. To allow a cost-effective introduction of UMTS, migration/evolution scenarios have been defined within ETSI, aiming at a smooth introduction of the new services and systems, starting from existing contemporary mobile and fixed telecommunication systems.
The need for enhanced security features in UMTS, has led to the definition of specific security objectives. These objectives have been translated into security requirements, resulting in a classification of security features. Mechanisms to realise the UMTS security features are currently under development. Secret key-based mechanisms, as well as public key-based mechanisms have been proposed for UMTS, providing mutual authentication, cipher key agreement for confidentiality, anonymity and non-repudiation. It must be stressed though, that security related migration issues cannot be addressed in isolation, but they should be investigated in the context of the overall network-based migration.
The objective of this paper is three-fold: (a) to propose a "general framework" for the migration of security offered by second generation systems (GSM, DCS1800, DECT) towards UMTS security, (b) to investigate the possible security enhancements in the different 'transition phases' and (c) to provide a flexible Authentication Framework which allows a number of different mechanisms and algorithms to be incorporated, along with the ability to migrate smoothly from one mechanism to another.
Security related migration issues cannot be addressed in isolation, but they should be investigated in the context of the overall network-based migration. The entities involved in the migration process (see Figure 1) are: (a) the SIM/UIM, (b) the Mobile Terminal Equipment, (c) the Access Network and (d) the Core Network, comprising the backbone network and the service network.
Figure
1 : The Entities Involved in the Migration
ProcessThe aim of this section is to provide a generic framework for the migration of security offered by second generation networks (GSM, DCS, DECT) towards UMTS security. The framework comprises two general steps:
Step 1. The identification of network-based migration scenarios. The migration scenarios will be based on the evolution of the access and core network, taking into account ETSI's SMG5 work [i]. The output of this step will be a number of "transition phases" separating successive "network levels" as shown in Figure 1.
Step 2. At each "transition phase", the (additional) security features that could be provided by the next network level are investigated. This step includes:
- the identification of the security features that could be provided,
taking into account the
network capabilities,
- the selection of the mechanisms to support them (performance and feasibility evaluation),
- the definition of security protocols and interfaces,
- the identification of messages exchanged between the various
entities (structure and
information conveyed),
- the impact on the terminals, SIMs, access and core network functionality, etc.
The outcome of the proposed framework is the identification and definition of the security features and relevant protocols for each "network level" appears in the migration process as described by the migration scenario.
The migration scenarios adopted in ASPeCT are a variant of the scenarios described in ETR 0104 []. Two differences between the ASPeCT and ETR approaches can be observed: (a) ASPeCT-level 1 corresponds to the ETR-level 2 and (b) ASPeCT-level 2 corresponds to ETR-level 3 without the introduction of the UMTS air-interface. The ASPeCT-levels 3 & 4 are similar to the corresponding ETR ones. During the migration path towards UMTS, three evolutionary steps are envisaged:
In the first step (ASPeCT-level 1 to level 2) the SIM/UIM and the home service provider (GSM SCP) are upgraded towards UMTS. A user equipped with a new multi-application UIM can use his/her UIM in a real UMTS network as well as in existing GSM/DCS or DECT networks, obtaining a limited set of UMTS services, due to the absence of the UMTS air-interface.
In the second step (ASPeCT-level 2 to level 3) the UMTS air-interface (Base Station Subsystem) is introduced. As a consequence, the core network (MSC/VLR) should handle the new A-interface and mobility management procedures.
In the last evolutionary step (ASPeCT-level 3 to level 4), "full" UMTS services and features are provided, either via a further evolved GSM/DECT operator infrastructure or via a UMTS target network infrastructure utilising B-ISDN as backbone network. The main modifications will reside in the core network enabling the provision of all UMTS services and features.
The security features envisaged for the intermediate "evolutionary levels" will be a compromise of the security features expected to be offered by third generation mobile systems. Based on this fact, two approaches can be foreseen: (a) The evolution (improvement or upgrade) of the contemporary GSM/DECT security features by implementing new, advanced security mechanisms and (b) The support of a subset of the security features expected to be offered by the UMTS.
Among the issues that have to be dealt with, during the application of the aforementioned approaches (or a combination of these) are:
It is apparent that the selection of the "appropriate" security features/mechanisms for the intermediate "evolutionary levels" is a very difficult task due to the various parameters introduced.
ASPeCT-level 2: Support of UMTS User Roaming over Ph2+ GSM Network Infrastructure: In ASPeCT-level 2 no new security features, compared to APeCT-level 1 are proposed. The UMTS UIM is introduced, able to support the GSM/DECT security mechanisms. The core network is still a second generation network and therefore can not cope with UMTS authentication procedures/ mechanisms. The possibility has been examined to deduct the GSM parameters from UMTS parameters. This however, creates limitations to the allowed format of the UMTS parameters and some GSM parameters can not be derived from UMTS parameters.
ASPeCT-level 3: Introduction of UMTS Air-Interface: For ASPeCT-level 3, a proposal is made to support a subset of the security features expected to be offered by UMTS. Due to changes foreseen in the A-interface and the mobility management procedures (to which the security procedures are closely linked), the introduction of almost all the UMTS security features is enabled. The introduction of UMTS in steps, according to the different levels, causes a need to prioritise the introduction of the UMTS security features and their associated mechanisms. The following security features/procedures are proposed for early introduction:
ASPeCT-level 4: Full UMTS: A list of expected third generation security features has been provided in D05 []. Within ASPeCT a framework for authentication has been proposed, reflecting the project's ideas on how flexibility can be introduced in the authentication procedures for the "target UMTS" system. This framework is presented hereafter.
The principle objective of the Authentication Framework is to provide a flexible procedure for user-network authentication allowing a number of different mechanisms and algorithms to be incorporated, with the ability to migrate smoothly from one mechanism to another. This framework allows the authentication capabilities of SIMs, network operators (NOs) and service providers (SPs) to be taken into consideration for the selection of the mechanism to be used. The interworking between the NO and the SP may involve a Certification Authority (CA). A list of capability classes (including the mechanisms supported) will need to be maintained so that different entities (SIMs, NOs, SPs and CAs) can permit the negotiation of the mechanisms to be used.
In order to facilitate roaming in a network with a large number of NOs and SPs, it might be desirable (or even necessary) for roaming agreements to be set-up dynamically, as and when they are required. In practice, the roaming agreement would be first requested as a result of an initial authentication request sent by the user/terminal to a network visited for the first time. A prerequisite of this procedure is that the SP and NO wishing to establish the agreement have authenticated each other.
NO-SP authentication will be carried out using a globally agreed mechanism in order to ensure that NOs and SPs world-wide have the capability to authenticate each other. Unlike the user-network authentication mechanism, flexibility to change mechanisms is not considered to be a crucial factor. Apart from being a prerequisite to a roaming agreement, NO-SP authentication will permit the SP to delegate user-network authentication to the NO. The SP would send authentication data to the NO in advance, permitting the NO to carry out authentication on behalf of the SP.
It should be noted that the identity of the User is not released until the stage of usernetwork authentication. The rationale for this is that the identity of the User is immaterial until the stage of authentication is reached; it is only the identity of the Service Provider which is required up until the stage of authentication. Note also that the identity of the User is never necessarily required by the Network Operator, hence temporary identities are used to provide party anonymity of the User towards the Network Operator.
A further characteristic of the Authentication Framework is the use of an authentication Capability Class, which acts to identify the particular authentication mechanisms which are supported by the UIM of a User. Each respective authentication mechanism is identified by an unique identifier. The rationale for this is that visited Network Operators may immediately identify whether they can support a particular Capability Class; unknown authentication mechanisms would be defined by the respective Service Provider upon request from the Network Operator.
As an example the operational scenario is described where a user,
not registered in the network, initiates authentication and no
roaming agreement exists between the Network and the user's service
provider. (Figure 2)
Figure
2 : Operational ScenarioThe user sends an initial message to a NO - this will include the user's service provider, authentication capability class, but not his identity nor his temporary identity. The NO does not have a roaming agreement with the SP so it initiates a procedure to establish one dynamically - if one cannot be established dynamically, then the request is refused. A procedure to establish a roaming agreement begins with the NO and SP authenticating each other. After authentication the NO and SP negotiate a roaming agreement which will involve each party digitally signing the agreement. Once an agreement has been established, the NO checks the authentication Capability Class of the User to establish if it is known. If it is known, the Network operator compares the associated authentication mechanisms with its own supported authentication mechanisms. If it is not known, the Network Operator sends the user's authentication capability class to his SP. The SP will respond by providing the NO with the authentication capabilities of that particular authentication capability class - this will include the authentication mechanisms the user is capable of handling. The NO will then choose an authentication mechanism, from those of the User's Capability Class, which is both supported by the Network Operator and by the User's UIM. The NO then sends the identity of the prescribed mechanism to the user. The authentication mechanism for new registrations involving the SP, NO and user is initiated. Note, however, that the SP may choose to delegate the actual authentication to a Certification Authority (CA).
Although it is impossible to define the "migration scenario" towards the "security features/mechanisms" of UMTS, this paper is aimed at reflecting the project's view on the migration towards UMTS security.
[1] ETSI Technical Report, "Scenarios and Considerations for the Introduction of the Universal Mobile Telecommunications System (UMTS)", DTR/SMG-050104, v.1.0.0, 1 April 1996.
[2] ETSI/SMG/ETR 050901, Security principles, version 2.5.0, SMG SG 141/96
[3] ACTS AC095,
Migration Scenarios, AC095/ATEA/W21/DS/P/05/2