AKA, the secured access to IMS systems

The IMS AKA Services are presented in the following articles and pages:

Background

IMS provides access to IP based multimedia services to 3G, 4G (LTE), and NGN terminals.

IMS provides three classes of services: Call services, Instant Messaging services, and Application services.

A key issue is how IMS services are secured from unauthorized use and how IMS subscriber's identities are protected.

IMS services and IMS subscribers are protected by IMS' AAA services.

AAA services and IMS
Figure F-22: AAA services and IMS

AAA is an acronym for Authentication, Authorization, and Accounting in IMS.

Authentication protects IMS services from illegal use and IMS subscribers from identity stealing and fraud.

Authorization validates an authenticated subscriber's rights to use a requested service.

Accounting charges subscribers for the use of requested services and monitors the need for closing on-going services that can't be paid for.

History

IMS AKA (Authentication and Key Agreement) is the 3GPP standard for secure sessions between User Equipment (UE) terminals and IMS systems.

Full IMS AKA security implementations were not possible, due to limitations both in 3G terminals and ISIMs.

The introduction of smart devices (smartphones pads etc.) changed this. Smart devices support all functionality required for IMS AKA registrations.

With continuous use of Internet services, smart devices also changed the subscriber behaviour, leading to a rapid growth in demand for bandwidth.

To manage the demand for bandwidth operators introduced LTE (or 4G) based services, which is the starting point for massive use of IMS and AKA.

The IMS AKA core functionality

AKA (Authentication and Key Agreement) is described in the 3GPP document TR 33.203 3G security; Access security for IP-based services, as well as in a number of RFCs, most important for an implementation on Linux are 2617, 3261 and 3310 (AKAv1).

The IMS AKA security mechanism has two main functions:

  1. Authentication of a UE (subscriber's device) by the home S-CSCF (Servicing CSCF) and the home S-CSCF by the UE.

  2. Protection of all traffic between a subscriber's device (UE) and the P-CSCF on the Gm interface on dual IPsec channels.

IMS AKA overview
Figure F-23: Secured sessions with IMS AKA

The SIP Register method is used to establish, extend, and terminate IMS AKA sessions.

The SIP Subscribe and Notify methods are used to monitor status of IMS AKA sessions.

To top of page

Requirements on IMS AKA performance test types

The IMS AKA services are critical to the availability of IMS services and consequently to the economic results of providing IMS services.

Consequently IMS AKA tests must include:

  • Powerfulness tests such as:

    • Arrival rate tests.

    • Throughput capacity tests.

    • Concurrency limit tests.

  • Reliability tests such as:

    • Stability tests.

    • Availability tests.

    • Robustness tests.

    • Recovery tests.

    • Accuracy tests.

To top of page

Requirements on IMS AKA performance test Tools

Requirements on test tool platform capacities

Both the authentication procedures and the set-up of protected traffic on two separate channels are resource demanding operations.

Performance tests of IMS AKA services require operating system support of large numbers of concurrent:

  • IPsec channels.

  • Security Associations (SAs) for IPsec channels.

  • IP addresses.

True simulation of 1,000,000 concurrent subscribers require:

  • 1,000,000 unique IP addresses.

  • 2,000,000 IPsec channels.

  • 4,000,000 Security Associations.

Such requirements on configuration capacity are far beyond the default settings of any standard operating system.

Management of key exchange, authentication, and IPsec channels with related Security Associations are resource damanding activities.

Yet management of these resources must be fast, regardless of number of concurrently simulated subscribers and reliable to support high transaction rates and reliability tests running for days or weeks.

Test tools must provide such capacities in one hardware box to keep the amount of hardware equipment at a minimum.

The MBC solutions for IMS AKA performance tests provide such platform capacities.

Requirements on test tool traffic capacities

Performance test tools for IMS AKA must be able to provide high traffic rates from large numbers of simulated subscribers.

The test tool must scale from less than 100,000 to 50,000,000 or even more simulated subscribers.

The traffic rates must be in the range 0.5% to 5.0% of the simulated users request an AKA session service every second, i.e. 500 - 5000 transactions per second per 1,000,000 simulated subscribers.

An MBC system provides scaling to any number of concurrently simulated subscribers.

To top of page