Home Subscriber Server (HSS)

This application implements the HSS network element within an IP Multimedia Subsystem (IMS) Core Network (CN).
IP Multimedia Subsystem (IMS)
The IMS is defined by the Third Generation Partnership Project (3GPP) as part of it's architecture for an all-IP 3G mobile
phone network. IETF protocols were chosen wherever possible, in particular SIP and DIAMETER. An IMS Core Network (CN)
can be seen mainly as a collection of SIP proxies, registrars, servers and media gateways along with the Home Subscriber
Server (HSS). While the IMS is based on SIP it is done so in a highly structured way which may be quite different from
practices used in other contexts. It should be remembered that the IMS was designed by and for service providers and as
such it has a centralized control model.
3GPP TS 23.002 Network Architecture describes an HSS:
The HSS is the master database for a given user. It is the entity containing the subscription-related information to support
the network entities actually handling calls/sessions. A Home Network may contain one or several HSSs: it depends on the
number of mobile subscribers, on the capacity of the equipment and on the organisation of the network. As an example,
the HSS provides support to the call control servers in order to complete the routing/roaming procedures by solving
authentication, authorisation, naming/addressing resolution, location dependencies, etc."
The HSS stores the following types of information: - subscription, identification and numbering - registration -
authentication and ciphering - service profile
The HSS generates security information for: - mutual authentication - communication integrity check - ciphering.
Network Architecture
Within an IMS CN the Call Session Control Functions (CSCF) provide the SIP proxy and registrar functionality. There are
three distinct types; Proxy-CSCF, Interrogating-CSCF and Serving-CSCF. All communications with IMS clients transit a P-
CSCF, possibly in a visited IMS. An example signaling flow can be seen in Figure-1.1 where the P-CSCF forwards an initial
REGISTER to an I-CSCF in the home IMS CN. The I-CSCF iqueries the HSS to help select an appropriate S-CSCF to forward
the request to. The S-CSCF acts as the registrar sending an authentication challenge to the user with authentication
vectors supplied by the HSS.
Figure-1.1
Once the user has successfully authenticated the S-CSCF will complete the registration and notify the HSS. While it is the
S-CSCF which acts as the SIP registrar the HSS must track which S-CSCF a user is registered at. An HSS may be associated
with many S-CSCFs. An IMS CN may contain more than one HSS.
Implementation
This project implements the (IMS) database schema described in 23.008 Subscriber Data, the procedures in 29.228
Signaling and the algorithms in 35.206 MILENAGE. It is based upon Release 7.
The system was developed entirely in Erlang/OTP using the Mnesia distributed database application. The procedures are
executed in mnesia transaction contexts and many servers may be run on many nodes for a very high capacity system. The
MILENAGE algorithms utilize the crypto application.
A number of test suites are included which use the common_test application. All of the conformance test data in 35.208 is
included in one test suite. The xmerl application is used in test cases to validate the XML user profile downloaded during
registration.
Database Schema
The schema in Figure 1.2 shows the organization of the permanent subscriber data. The HSS maintains the data related to
Subscribers of IMS services. Each subscription may include a number of Users of the subscribed services. Users are
identified within the IMS by a Private User Identity in the (NAI) form "user@realm". All communications with a user
involves a Public User Identity in the form of either a SIP URI or a TEL URL. Users can, and usually are, associated with
multiple Public User Identities which may also be shared among users of a common subscription. The subscribed services
are associated with Public User Identities. Subscriptions are represented by records in the subscriber table, Users in the
user table, Public User Identities in the address table and Service Profiles is the profile table.
Figure 1.2

Registrations are temporary subscriber data describing the registration status of Public User Identities including the name of the S-CSCF where the registration is held. A Public User
Identity may be registered by several users at the same time and so multiple entries with registered state may appear in the table for the same identity. An S-CSCF may keep a user
profile stored without any registrations in some cases so one entry with unregistered state may remain in the table. An unregistered Public User Identity will generally not have a record
in the table. One or more entries with notregistered state may exist while authentication is pending. The schema in Figure 1.3 shows the organization of the temporary subscriber data.
Figure 1.3

Provisioning
In a conventional operator network a large number of Universal Integrated Circuit Cards (UICC) would be manufactured and put into the the distribution channel. The UICCs may
contain an IP Multimedia Services Identity Module (ISIM) application or a Universal Subscriber Identity Module (USIM) application or both. The manufacturer would provide a file listing
the ICCIDs and the corresponding authentication keys (K and OPc) as well as IMS Private User Identity (IMPI) and IMS Public User Identity (IMPU) in the case of an ISIM, or International
Mobile Subscriber Identity (IMSI) in the case of a USIM. This file is used to manage the card inventory.

Figure 1.4

To provision a new subscriber a card is taken from inventory and it's ICCID is used to determine the identities and keys stored on the UICC. Appropriate Public User Identities are
assigned and a Service Profile is selected for each one. A new subscriber and user table entry are created along with address table entries for each Public User Identity.
Figure 1.5

It is mandatory that at least one Public User Identity record is contained in the ISIM application however it is usually not practical to assign appropriate Public User Identities at the time
of manufacture. Assigning Public User Identities is typically done after a card is drawn from inventory and a subscriber identifies which city a telephone number should be assigned from
or what name to use in a SIP URI. This could be managed by administratively writing to the card before providing it to the subscriber but it is more convenient to manage address
assignment entirely within the HSS. This can be accomplished by manufacturing the UICCs with a default IMPU, usually formed from the IMPI, and provisioning it as barred. When the
UICC is inserted in the User Equipment (UE) it will read the ISIM and attempt to register the default IMPU. For example:
REGISTER sip:323.248.imsi.3gppnetwork.org SIP/2.0
From: <sip:2483235551234@323.248.imsi.3gppnetwork.org>;tag=4fa3
To: <sip:2483235551234@323.248.imsi.3gppnetwork.org>
Authorization: Digest username="2483235551234@323.248.imsi.3gppnetwork.org",
realm="323.248.imsi.3gppnetwork.org", nonce="",
uri="sip:323.248.imsi.3gppnetwork.org", response=""
The same situation arises when the UICC contains only a USIM application. The IMS user equipment will read the USIM application and form a Temporary Private User Identity and
Temporary Public User Identity derived from the IMSI. The entire IMSI is used as the username part of the Private User Identity and the realm is constructed from the Mobile Network
Code (MNC) and Mobile Country Code (MCC) and follows the form MNC.MCC.imsi.3gppnetwork.org. The Public User Identity is formed by prepending "sip:" to the Private User Identity.

In the final response to a successful registration the P-Associated-URI header will contain the list of all non-barred Public User Identities associated with the registered identity. The UE
will understand that it may not use the default temporary identity for communications and will recognize the assigned identities.
SIP/2.0 200 OK
From: <sip:2483235551234@323.248.imsi.3gppnetwork.org>;tag=4fa3
To: <sip:2483235551234@323.248.imsi.3gppnetwork.org>;tag=409sp3
P-Associated-URI: <sip:alex.harvey@vibrania.com>,
<sip:+16475551234@acme.net;user=phone>

Security
Security in the IMS is built on UMTS Authentication and Key Agreement (AKA. A long term secret (K) is shared between the
USIM/ISIM and the HSS only. The AKA algorithms are executed on the UICC which is tamper resistant so even physical
access to it is unlikely to expose K. AKA accomplishes mutual authentication, the home network authenticates the
USIM/ISIM which in turn authenticates the network. It also establishes a pair of cipher and integrity keys which can be
used to secure subsequent communications (i.e. IPsec).
AKA defines seven security functions; f1, f1*, f2, f3, f4, f5 and f5* used for authentication and key generation. The
operation of these functions is to be specified by each operator and as such is not fully standardised. The algorithms
implemented here follow the examples produced on request from 3GPP by ETSI SAGE Task Force (MILENAGE) and are
based on the block cipher Rinjindael now known as Advanced Encryption Standard (AES).