Study Program Master Telecommunications and Internet Technologies

Course Application Prototyping

LECTURE NOTE 4
Version: Datum: 2.2 12.03.2010

IP MULTIMEDIA SUBSYSTEM (IMS)

Identities, Authentication and Registration

Dipl.-Ing. Franz Edler

Part 4: IMS Identities, Authentication and Registration

CONTENTS:
1. Overview................................................................................................................................ 3 1.1. Content of the course ....................................................................................................... 3 1.2. Structure of the course ..................................................................................................... 3 1.3. Preconditions and further readings and exercises.............................................................. 3 1.4. Questions and exercises ................................................................................................... 4 1.5. Target audience................................................................................................................ 4 2. IMS Identities......................................................................................................................... 5 2.1. The Public User Identity (IMPU) ..................................................................................... 5 2.2. The Private User Identity (IMPI)...................................................................................... 5 2.3. Relationship between Private and Public User Identities .................................................. 6 2.4. The Public Service Identity .............................................................................................. 6 2.5. The Universal Integrated Circuit Card (UICC) ................................................................. 7 2.5.1. Subscriber Identity Module (SIM)............................................................................. 7 2.5.2. Universal Subscriber Identity Module (USIM) .......................................................... 7 2.5.3. IMS Subscriber Identity Module (ISIM).................................................................... 7 3. IMS registration.................................................................................................................... 10 3.1. The simple SIP registration ............................................................................................ 10 3.2. The more complex IMS registration............................................................................... 11 3.3. Other registration algorithms.......................................................................................... 20 3.3.1. GPRS-IMS-bundled Authentication ........................................................................ 20 3.3.2. NASS-IMS-bundled authentication ......................................................................... 20 3.3.3. TLS Connection Establishment ............................................................................... 21 3.3.4. Summary on access security algorithms .................................................................. 21 3.4. The subscription to the Registration Event State............................................................. 22 3.5. A few remarks on the role of the P-CSCF during registration......................................... 24 4. Exercises and Questions ....................................................................................................... 25 5. References............................................................................................................................ 28 5.1. Books on Session Initiation Protocol.............................................................................. 28 5.2. Books on IP Multimedia Subsystem............................................................................... 28

Author: Dipl.-Ing. Franz Edler

page: 2 / 28

Part 4: IMS Identities, Authentication and Registration

1. OVERVIEW
1.1. CONTENT OF THE COURSE
The course offers in depth knowledge on the IP Multimedia Subsystem (IMS). IMS means the architecture and concepts of the new Internet based communications networks, which will replace the traditional TDM1 based fixed and mobile networks in the coming years. The IP Multimedia Subsystem is based on SIP2 and therefore will provide not only voice services (telephony) but also multimedia communications. The IMS further on enables the integration of all available internet protocols and services even if not known today.

1.2. STRUCTURE OF THE COURSE

The course actually comprises the following parts: 1. IMS Overview and Standards 2. Basic Technologies: SIP recap and new protocols and extensions 3. IMS network architecture 4. IMS Identities, Authentication and Registration 5. Basic Session Control 6. User Profile and Provision of Services 7. Charging and Security Architecture 8. Access networks and PCC 9. Presence and Push-to-Talk 10. PSTN Simulation and Emulation 11. IP-TV

1.3. PRECONDITIONS AND FURTHER READINGS AND EXERCISES

The students should have as precondition for this course a solid background in basic internet technologies, in SIP and some of the SIP protocol extensions. Part 2 of this course (Basic Technologies) covers some of the mentioned technologies more as a short recap without offering all details. The student is encouraged to recap the knowledge from other courses, other literature or the Internet3. The author also encourages the students to look up in the mentioned standards, because this is the only firm basis in case of some issues and discussions in your future professional career. There are also some books available, which give deep insight into IMS. Two of them (the yellow and the red book) are preferred by the author. But of course there are more books available meanwhile and further books will come up in the future (see chapter 0). For the best result of the course practical exercises should be done in parallel. The Open IMS Core project of Fraunhofer Fokus4 (an Open Source project) offers an ideal basis to challenge
1 2

TDM = Time Division Multiplex SIP = Session Initiation Protocol, RFC 3261 3 I strongly recommend the Tech-Invite portal http://www.tech-invite.com/ 4 Open IMS Core project of Fraunhofer Fokus http://www.openimscore.org/

Author: Dipl.-Ing. Franz Edler

page: 3 / 28

Part 4: IMS Identities, Authentication and Registration the theoretical knowledge. Due to the limited amount of time for the course the author can only give some hints and examples how to handle the Open IMS Core software on Linux. To overcome the barriers of installation a VMware image of Open IMS Core is also available for download including some How-To instructions. There is also an implementation of OpenIMSCore on a public server of the University available, which gives a more realistic environment for e.g. development of master theses of students.

1.4. QUESTIONS AND EXERCISES

At the end of each part the student can find some questions which should help to get feedback on the core points of the course. The student should be able to answer the questions and exercises at the end of the course.

1.5. TARGET AUDIENCE

The target audience of this course are students on bachelor degree in the upper classes on telecommunications systems and students for the master degree of Telecommunications und Internet-technology.

Author: Dipl.-Ing. Franz Edler

page: 4 / 28

Part 4: IMS Identities, Authentication and Registration

2. IMS IDENTITIES
Every communications network requires that its users can be addressed. There are MAC addresses on the link layer, IP addresses at the network layer and on the application layer which is IMS in our case there are also specific identities to address users and services5.

2.1. THE PUBLIC USER IDENTITY (IMPU)

An IMS user has one or more Public User Identities in the format of SIP URIs or TEL URIs. The Public User Identities are the identities known to other communication partners and used to route requests through the IMS network. IMS enables terminals to use more than one Public User Identity in parallel. The same terminal can therefore be used e.g. for private6 and business purposes. The Public User Identities may be associated with different service profiles and this allows a user e.g. to activate a call diversion to a mailbox for business calls during weekend while still being reachable for calls addressed to his private identity. The Public User Identity is expected to be a typical SIP URI like sip:first.last@operator.com including a non numeric user part (typically the name of the user). PSTN/ISDN and also telephone number oriented mobile networks7 which are in use today will still be in operation during the next years. Therefore it is important for an IMS user to be also reachable via a traditional phone number and in fact each IMS user will always have an additional TEL URI allocated in parallel to a SIP URI. Such a TEL URI looks like tel:+43-2252-48078. The + sign identifies the telephone number as an international format number including a country code prefix. Besides the common Public User Identity which addresses exactly one user, there are also wildcarded Public User Identities defined. These wildcarded Public User Identities are used to address a set of Public User Identities which are grouped together and which is typically used for registration of a group of users (e.g. PABX8).

2.2. THE PRIVATE USER IDENTITY (IMPI)

The Private User Identity is in contrast to the Public User Identity a hidden identity of an IMS terminal and it is used only for authentication during the IMS specific registration procedure (see chapter 3). The Private User Identity is not a SIP URI but a Network Access Identifier (NAI9), which looks quite similar, but the obvious difference to a SIP URI is the missing sip: scheme. A typical Private User Identity looks like username@realm. The realm of the Private User Identity usually corresponds to the domain name of the operator. The Private User Identity may not be known to the customer. It corresponds to the IMSI (International Mobile Subscriber Identity) in GSM networks.

5 6

Details can be found in TS 23.003: Numbering, addressing and identification To avoid confusion: also the private identity in this example is addressed by a Public User Identity! 7 The world-wide telephone numbering scheme is structured according to ITU-T Recommendation E.164. Therfore we often speak about E.164 numbers. 8 PABX = Private Automatic Branch Exchange 9 RFC 4282: The Network Access Identifier

Author: Dipl.-Ing. Franz Edler

page: 5 / 28

Part 4: IMS Identities, Authentication and Registration

2.3. RELATIONSHIP BETWEEN PRIVATE AND PUBLIC USER IDENTITIES

The Relationship between Private and Public User Identities is depicted in Figure 1 as it is defined in Release 8. The IMS subscription on the left side corresponds to the legal contract of an IMS subscriber with a service provider. A subscriber may use more than one IMS terminal and in this case he requires more than one Private User Identity because a Private User Identity corresponds to an ISIM application on an UICC card. Each terminal in a 3GPP network needs an ISIM and therefore more than one Private User Identity may be required by a subscriber who uses more than one terminal. Each Private User Identity may have one ore more Public User Identities assigned. Interestingly the same Public User Identity may be allocated to multiple Private User Identities. This enables the well known SIP forking behaviour where more than one IMS terminal is addressed with the same Public User Identity. Service Profiles are assigned to all Public User Identities. The Service Profiles can be different for different Public User Identities or the Service Profiles can also be shared among several Public User Identities. Due to this structure we can expect a lot of flexibility in assigning identities and service profiles.

Public User Identity 1 Implicitly Registered ID Set 1

Service Profile 1

Private User Identity 1

Public User Identity 2

Service Profile 2

Public User Identity 3 IMS Subscription Public User Identity 4 Implicitly Registered ID Set 2

Service Profile 3

Private User Identity 2

Public User Identity 5

Public User Identity 6

Implicitly Registered ID Set 3

Service Profile 4

Figure 1: Relationship between Private and Public User Identities (TS 23.228)

2.4. THE PUBLIC SERVICE IDENTITY

Besides subscriber oriented identities there are also service oriented identities defined. Unlike the Public User Identities (PUID), which are allocated to user, Public Service Identities (PSI) are identities allocated to services hosted by application servers. For instance, an application server hosting a chat room service or a voice-mail service may be identified by a PSI. Author: Dipl.-Ing. Franz Edler page: 6 / 28

Part 4: IMS Identities, Authentication and Registration Like Public User Identities, PSIs may take the format of a SIP URI or a TEL URL. Unlike Public User Identities, PSIs do not have an associated Private User Identity because they do not need an IMS registration and authentication procedure to be reachable. There are two categories of PSIs defined: distinct PSI and wildcard PSI. A wildcard PSI allows a certain address pattern to be routed towards an application server. A chat room service may be addressed by the wildcard PSI "sip:chatlist!.*!@example.com" whereby the ! is a delimiter for the regular expression. For routing of requests addressed to a PSI there are several possibilities. The most obvious one is to use iFCs (initial Filter Criteria10) to forward requests to the AS hosting the PSI but an alternative may also be to forward a PSI directly to the I-CSCF to the AS (domain based routing).

2.5. THE UNIVERSAL INTEGRATED CIRCUIT CARD (UICC)

The Universal Integrated Circuit Card is a central component in the access security architecture at least in mobile networks. The UICC is the well known smart card used in mobile handsets today. It is used to store, among other things, subscription information, authentication keys, phonebook, and messages. The UICC contains various applications and the following identity modules are applications of an UICC. 2.5.1. SUBSCRIBER IDENTITY MODULE (SIM) The Subscriber Identity Module (SIM) is well known term in mobile networks of 2nd generation (GSM). Erroneously the UICC card is often termed SIM card but as explained above SIM is an application on the UICC. The SIM application provides storage for a collection of parameters (e.g., user subscription information, user preferences, authentication keys, and storage of messages) that are essential for the operation of terminals in GSM networks. 2.5.2. UNIVERSAL SUBSCRIBER IDENTITY MODULE (USIM) The USIM (Universal Subscriber Identity Module) is another example of an application that resides in UICCs for third-generation mobile networks (UMTS). An USIM provides another set of parameters (similar in nature, but different from those provided by SIM) which include user subscriber information, authentication information, payment methods, and storage for messages. The USIM is used to access UMTS networks. The USIM application may be present on an UICC in addition to a SIM application. 2.5.3. IMS SUBSCRIBER IDENTITY MODULE (ISIM) A third application that may be present in the UICC is the ISIM (IMS Subscriber Identity Module )11. The ISIM application is important for the IMS, because it contains the collection of parameters that are used for user identification, user authentication and terminal configuration when the terminal operates in the IMS. An ISIM can co-exist with a SIM, with a USIM or with both applications in the same UICC.
10 11

Details on iFC are covered in part 6 of the lecture. 3GPP TS 31.103: Characteristics of the IP Multimedia Services Identity Module (ISIM) application

Author: Dipl.-Ing. Franz Edler

page: 7 / 28

Part 4: IMS Identities, Authentication and Registration Figure 2 depicts the structure of the ISIM application. The relevant parameters stored in ISIM are as follows: Private User Identity: Public User Identity: ISIM stores the Private User Identity allocated to the user. There can only be one Private User Identity stored in ISIM. ISIM stores one or more SIP URIs of Public User Identities allocated to the user.

Home Network Domain URI: ISIM stores the SIP URI that contains the home network domain name. This is used to find the address of the home network during the registration procedure. There can only be one home network domain name URI stored in ISIM. Long-term secret: ISIM stores a long-term secret that is used for authentication purposes and for calculating the integrity and cipher keys used between the terminal and the network. The IMS terminal uses the integrity key to integrity-protect the SIP signalling that the IMS terminal sends to or receives from the P-CSCF. If the signalling is encrypted, the IMS terminal uses the cipher key to encrypt and decrypt the SIP signalling that the IMS terminal sends to or receives from the P-CSCF.

All of the above-mentioned fields are read-only, meaning that the user cannot modify the values of the parameters. In addition the chip itself is designed to be tamper-proof, and information stored on the card is protected from theft, forgery or duplication.

ISIM
Private User Identity

Public User Identity 1n

...
Public User Identity Public User Identity

Home Network Domain URI

Long-term Secret

Figure 2: Structure of an ISIM application Author: Dipl.-Ing. Franz Edler page: 8 / 28

Part 4: IMS Identities, Authentication and Registration

During early introduction of IMS it might be an economic and logistic problem to exchange UICC cards with a SIM or USIM application with an additional ISIM application. Therefore special algorithms have been defined as a workaround to derive the necessary parameters for Access to the IMS from parameters of a SIM or USIM application. This leads to some restrictions in the assignment of identities. In case of SIM the derived algorithms cannot provide the same strong security features but that may be acceptable for a transition period.

Author: Dipl.-Ing. Franz Edler

page: 9 / 28

Part 4: IMS Identities, Authentication and Registration

3. IMS REGISTRATION
3.1. THE SIMPLE SIP REGISTRATION
SIP already offers a registration procedure based on the REGISTER method. The registrar server usually verifies the identity of a user with help of the HTTP digest algorithm. The principle registration procedure in SIP is shown in Figure 3.

Figure 3: Registration in a SIP network The SIP user agent (UA) sends a REGISTER request (1) to the registrar server of its domain. The REGISTER request contains the AoR (Address-of-Record) of the registering user in the To header field and usually also in the From header field12. The first REGISTER request usually does not include the credentials (username/password) of the user. Therefore the registrar rejects the REGISTER request with a 401 Unauthorized response (2). This failure response contains a WWW-Authenticate header field with a realm and a nonce parameter value which is offered to the UA for authentication. The UA then sends a second REGISTER (3) request including an Authorization header field with a username and a response parameter value. The value of the response parameter is the result of a digest calculation including among other the nonce value, the username and the password. After successfully verifying the response parameter the registrar server accepts the registration and responds with 200 OK (4). In SIP (as with HTTP from where the Digest Authentication procedure is reused) only a one-way authentication is used: the server always authenticates the client. But in principle also a two-way (mutual) authentication can be applied. The client may also authenticate the server but this is rarely used. From above procedure we see that the registration procedure in SIP usually needs two REGISTER transactions to be successful.

12

Remember: Only in case of a 3rd party registration the From header field is different from To header field. It contains the identity of the registering user

Author: Dipl.-Ing. Franz Edler

page: 10 / 28

Part 4: IMS Identities, Authentication and Registration

3.2. THE MORE COMPLEX IMS REGISTRATION

Within IMS the same REGISTER based registration mechanism is used, but the HTTP digest algorithm of RFC 261713 has some limitations which have not been accepted by 3GPP, e.g.: The username/password combination can be re-used by anyone else if disclosed. No session keys are generated during authentication.

Therefore the HTTP digest algorithm has been enhanced by 3GPP with an Authentication and Key Agreement (AKA) mechanism which performs user authentication and session key distribution in UMTS networks14. The secret key is shared between the IMS terminal and the HSS, but because the HSS only talks diameter the role of a registrar server is delegated to the S-CSCF. Like in the simple SIP registration based on the HTTP digest algorithm the HTTP Digest Authentication with AKA also only requires two REGISTER transactions. But there is a list of additional tasks which are accomplished now during the registration procedure as follows: An S-CSCF out of a pool of S-CSCF is selected and assigned to the UE. The authentication is a mutual one. The network authenticates the user but also the user authenticates the network. An encryption and an integrity key are provided to protect the first hop (from IMS terminal to the P-CSCF). A security mechanism is negotiated between the IMS terminal and the P-CSCF. The negotiation procedure also prevents a bid-down attack by a man-in-the middle (based on Security-Client, Security-Server and Security-Verify header). Security associations (IPsec based) are setup between the IMS terminal and the P-CSCF. A signalling compression algorithm is negotiated (comp-parameter). A service-route is provided by the S-CSCF to be used by the IMS terminal as a preloaded signalling Route (Service-Route header). The path is created and stored by the S-CSCF by which the S-CSCF always knows how the IMS terminal can be reached (Path header). In case the P-CSCF is in a visited network the home network verifies if a valid roaming agreement exists and if the user is allowed to roam. The home network informs the user about additional Public User Identities which the user may use.

Care has been taken to include all above mentioned additional tasks within the two REGISTER transactions to not increase the number of round trips. Therefore the registration procedure is somewhat overloaded compared to the simple SIP registration mechanism shown in Figure 3. Additional information elements are piggybacked on REGISTER requests and responses. Figure 5 shows the registration message flow in IMS and Figure 4 shows an example content of the REGISTER request (message 1) sent by an IMS terminal to the P-CSCF.

13 14

RFC 2617: HTTP Authentication RFC 3310: HTTP Digest Authentication using AKA (AKAv1-MD5)

Author: Dipl.-Ing. Franz Edler

page: 11 / 28

Part 4: IMS Identities, Authentication and Registration Compared with the REGISTER request in a simple SIP registration we can recognize in Figure 4 the following differences and additions: The physical IP addresses in Via and Contact header are IPv6-addresses. Via and Contact header contain a comp=sigcomp parameter to tell the P-CSCF that signalling compression is supported by the IMS terminal. The P-Access-Network-Info header field carries information about access technology and location. The expires value at the Contact header field is rather high (600000 seconds which is about 7 days). Background: the short term periodic refresh is not necessary due to the security association between UE and P-CSCF which is activated during initial registration. An Authorization header field is already present in the first REGISTER request. It contains the username parameter with the value of the private user identity and the realm parameter with the name of the home network. The Security-Client header field contains parameters for the security association: - security mechanism (ipsec-3gpp) - authentication algorithm (hmac-sha-1-96) - encryption algorithm (ealg=aes-cbc) - security parameter IDs (spi) and port numbers for the security associations The Require and Proxy-Require header fields request the sec-agree extension15. The Supported header field shows support for the Path header extension.

REGISTER sip:homel.net SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net> Contact: <sip:[1080::8:800:200C:417A];comp=sigcomp>;expires=600000 Call-ID: 23fi571ju Authorization: Digest username="alice_private@homel.net", realm="homel.net",nonce="",uri="sip:homel.net", response="" Security-Client: ipsec-3gpp; alg=hmac-sha-l-96; ealg=aes-cbc; spi-c=3929102; spi-s=0293020;port-c:3333; port-s=5059 Require: sec-agree Proxy-Require: sec-agree Cseq: 1 REGISTER Supported: path Content-Length: 0

Figure 4: (1) REGISTER The complete IMS registration flow is shown in Figure 5. In addition to the two REGISTER transactions this figure also shows the diameter transactions between I/S-CSCF and the HSS and
15

RFC 3329: Security Mechanism Agreement for SIP

Author: Dipl.-Ing. Franz Edler

page: 12 / 28

Part 4: IMS Identities, Authentication and Registration two subscriptions to the registration event: one subscription by P-CSCF and another by the IMS terminal. Before the IMS terminal sends the first REGISTER request it retrieves from the ISIM the Private User Identity, a Public User Identity, and the home network domain URI. These three parameters are used as follows: The home network domain is used to address the REGISTER request towards the responsible network (request URI of the REGISTER request) A Public User Identity is used as Address-of-Record in To and From header field. In case more than one Public User Identity is contained on the ISIM one is selected for the registration. The Private User Identity is used for authentication. It is used as username parameter value in the Authorization header.
IMS Terminal
(1) REGISTER (2) REGISTER (3) Diameter UAR (4) Diameter UAA (5) REGISTER (6) Diameter MAR (7) Diameter MAA (8) 401 Unautorized (9) 401 Unautorized (10) 401 Unautorized (11) REGISTER (12) REGISTER (13) Diameter UAR (14) Diameter UAA (15) REGISTER (16) Diameter SAR (17) Diameter SAA (18) 200 OK (19) 200 OK (20) 200 OK

P-CSCF

I-CSCF

HSS

S-CSCF

(21) SUBSCRIBE (22) 200 OK (23) NOTIFY (24) 200 OK (25) SUBSCRIBE (26) SUBSCRIBE (27) 200 OK (28) 200 OK (29) NOTIFY (30) NOTIFY (31) 200 OK (32) 200 OK

Figure 5: Complete IMS registration flow including subscription to reg event

Author: Dipl.-Ing. Franz Edler

page: 13 / 28

Part 4: IMS Identities, Authentication and Registration

The IMS terminal sends the REGISTER request (1) to the P-CSCF which it has discovered during the IP attachment procedure. The P-CSCF then inserts a P-Visited-Network-ID header field which identifies the network where the P-CSCF is located and sends the REGISTER, Path header-field with its own URI to request the home network of the user to send all requests towards the user through this P-CSCF, and a P-Charging-Vector header field for charging purposes.

After this additional modifications (the regular SIP protocol based modifications like inserting a Via header field are not mentioned here) the P-CSCF sends the REGISTER request (2) to an I-CSCF in the home network of the user. But how does a P-CSCF know the addresses of an I-CSCF of the home network of the user? The P-CSCF queries the DNS for addresses of SIP server(s) of the respective domain16. The addresses of the I-CSCFs therefore have to be published in the DNS by each network provider. The I-CSCFs shield the core network of S-CSCFs from direct access by other domains and they often operate in a loadsharing mode. The I-CSCF does not have any state information about users of the network, but it has access to the HSS and therefore it queries the HSS (this is where the name Interrogating comes from). The I-CSCF sends a diameter UAR (User Authentication Request) to the HSS (3). The UAR contains the three parameters (as AVPs) - Private User Identity - Public User Identity - Visited Network Identifier which the I-CSCF extracts from the REGISTER request. The HSS checks if a user with the mentioned Private and Public User Identity exists and if it is allowed to roam in the mentioned visited network. The answer of the HSS is a diameter UAA request (User Authentication Answer). The UAA contains - in case on an initial registration: a set of capabilities which are required to support the registering user, or - in case of a subsequent registration: the address (SIP URI) of an already allocated S-CSCF. The I-CSCF uses the set of capabilities which it receives in case of the first registration of a user to select an appropriate S-CSCF. There are mandatory and optional capabilities17 and the I-CSCF has the knowledge about all available S-CSCF in the network and their capabilities. Now the I-CSCF selects an S-CSCF (or uses the already allocated one) and forwards the REGISTER request to the selected S-CSCF (5). The REGISTER request may now look as shown in Figure 6. What is the difference of above REGISTER request compared to the REGISTER sent by the IMS terminal?

This is the well known Locating SIP servers procedure defined in RFC 3263 and not shown in the flow diagram. Due to caching mechanisms the explicit DNS query is usually only done once during the TTL (time-tolive). 17 The capabilities are not defined in the standard only the selection mechanism. The capabilities have a numeric value and their semantics are defined by the network operator.

16

Author: Dipl.-Ing. Franz Edler

page: 14 / 28

Part 4: IMS Identities, Authentication and Registration Of course we now have three VIA-header fields (only the first has the comp=sigcomp parameter) The Authorization header field has got the additional parameter integrity-protected added by the P-CSCF, which reflects that this time the REGISTER request is not integrity protected. There is the Supported and Required header field for the path feature and the Path header field, which contains the address of the P-CSCF (only18). These have been inserted by the P-CSCF. The address in the Path header will be used by the S-CSCF to populate the Route header field in case of terminating requ ests. The pseudo-user term will tell the P-CSCF in that case that the routing is a terminating one. There is the P-Visited-Network-ID header field added by the P-CSCF which reveals that the user is actually roaming. The P-Charging-Vector header field inserted by the P-CSCF contains the icid-parameter. This parameter (IMS charging identifier) uniquely identifies a transaction en-route trough all network nodes. This helps to correlate charging messages generated by different nodes during a transaction.

REGISTER sip:homel.net SIP/2.0 Via: SIP/2.O/UDP icscfl.homel.net;branch=z9hG4bKealdof, SIP/2.O/UDP pcscfl.visitedl.net;branch=z9hG4bKoh2qrz, SIP/2.O/UDP [1080::8:800:200C:417A];comp=sigcomp;branch=z9hG4bK9h9ab Max-Forwards: 68 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net> Contact: <sip:[1080::8:800:200C:417A];comp=sigcomp>;expires=600000 Call-ID: 23fi571ju Authorization: Digest username="alice_private@homel.net", realm="homel.net", nonce="",uri="sip:home1.net",response="", integrity-protected="no" Require: path Supported: path Path: <sip:term@pcscf1.visitedl.net;lr> P-Visited-Network-ID: "Visited 1 Network" P-Charging-Vector: icid-value="W34h6dlg" Cseq: 1 REGISTER Content-Length: 0

Figure 6: (5) REGISTER When the S-CSCF receives the REGISTER request it takes the role of a SIP registrar server. The S-CSCF itself does not have any authentication data (e.g. username, secret key ) of a user; these are strictly kept within the HSS. To be able to authenticate the user the S-CSCF asks the HSS for one or more19 authentication vectors with a diameter request MAR (Multimedia
18

In principle other network nodes en-route to the S-CSCF can add their address. Up to now this might be done by the I-CSCF when it cares for topology hiding. The Path header will than contain two addresses. 19 The S-CSCF may request more than one authentication-vector for a user to avoid contacting the HSS every time it needs to authenticate the user again.

Author: Dipl.-Ing. Franz Edler

page: 15 / 28

Part 4: IMS Identities, Authentication and Registration Authentication Request) and additionally informs the HSS that it is now (preliminarily) assigned for this user. The HSS returns the authentication vector(s) in a diameter MAA (Multimedia Authentication Answer) message. An authentication vector contains a quintuple of data: - a random challenge value (RAND), - the expected answer of the terminal (XRES), - a network authentication token (AUTN), - a session key for integrity check (IK) and - a session key for encryption (CK). The HSS creates above parameters based on the secret key that it shares with the IMS terminal. The S-CSCF now inserts RAND, AUTN, IK and CK into the WWW-Authenticate header field of a 401 Unauthorized response according to the HTTP Digest AKA. RAND and AUTN are concatenated and coded into the nonce parameter of the HTTP-digest algorithm. IK and CK value are added as separate parameters. The XRES parameter is kept by the S-CSCF to check if the next REGISTER request contains the correct response parameter. The resulting 401 Unauthorized response sent by the S-CSCF is shown in Figure 7 .
SIP/2.0 401 Unauthorized Via: SIP/2.O/UDP icscfl.homel.net;branch=z9hG4bKealdof, SIP/2.O/UDP pcscfl.visitedl.net;branch=z9hG4bKoh2qrz, SIP/2.O/UDP [1080::8:800:200C:417A];comp=sigcomp;branch=z9hG4bK9h9ab From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net>;tag=409sp3 Call-ID: 23fi571ju WWW-Authenticate: Digest realm="homel.net", nonce=Mdcd98b7102dd2i0e8blld0i600bib0c093", algorithm=AKAvl-MD5,ck="79b1f9534ac95134a31cdc50247d011c", ik="4ef7e4dfadbab533b3ffbb17f8495a5d" Cseq: 1 REGISTER Content-Length: 0

Figure 7: (8) 401 Unauthorized The 401 Unauthorized response is sent via I-CSCF to the P-CSCF (well known response routing based on the Via header field). The P-CSCF now strips the ck and ik parameter from the WWW-Authenticate header field and additionally inserts a Security-Server header field. The ck and ik parameter are stripped because if these are transported on an unencrypted channel it would make the keys useless, they could easily be read by an attacker. The Security-Server header field inserted by the P-CSCF contains the offered security algorithms and the security parameters for the security association to be set-up. The 401 Unauthorized response finally received by the IMS terminal is shown in Figure 8.

Author: Dipl.-Ing. Franz Edler

page: 16 / 28

Part 4: IMS Identities, Authentication and Registration

SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp; branch=z9hG4bK9h9ab From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net>;tag=409sp3 Call-ID: 23fi571ju WWW-Authenticate: Digest realm="homel.net", nonce=Mdcd98b7102dd2i0e8blld0i600bib0c093", algorithm=AKAvl-MD5 Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; ealg=aes-cbc; spi-c=909767; spi-s=421909; port-c:4444; port-s=5058 Cseq: 1 REGISTER Content-Length: 0

Figure 8: (10) 401 Unauthorized The IMS terminal now recognizes that it is unauthorized and that it has to authenticate according to the AKAv1-MD5 algorithm. It first extracts AUTN and RAND out of the nonce value. AUTN is used by the IMS terminal to authenticate the network20. It than produces the response to the challenge (RAND value) and also re-calculates the encryption and integrity keys (based on the RAND value) that have been eliminated by the P-CSCF. The CK and IK value together with the Security-Client and Security-Server header fields enable the IMS terminal to setup two secure associations with the P-CSCF (one for each direction) and to send the second REGISTER request already encrypted and integrity protected to the P-CSCF. This REGISTER request is shown in Figure 9. Compared with the first REGISTER request in Figure 4 the second REGISTER request(11) now contains - the nonce and response parameter in the Authorization header and - a Security-Verify header field that mirrors the content of the Security-Server header field. The second REGISTER request (11) is shown in Figure 9. The IMS terminal again sends this REGISTER request (11) to the P-CSCF. An additional important difference to the first REGISTER request is, that now the request is already encrypted and integrity protected and it is sent/received on the ports exchanged in Security-Client and Security-Server header field parameters. The P-CSCF decrypts the received REGISTER request and validates it integrity based on the CK and IK value it previously has kept back. If the validation is successful it adds an integrity-protected parameter with value yes to the Authorization header field and forwards the request to an I-CSCF (12). From now on the request in not encrypted and integrity protected anymore because it is now sent within the trusted area. The Security-Verify header field protects against a bid-down attack21. The P-CSCF would immediately recognize a manipulation as long as it cannot be done in real-time. The I-CSCF which may be a different one than the I-CSCF used at the first REGISTER request due to e.g DNS based load balancing again asks the HSS in a diameter sequence (UAR/UAA) for routing information to an S-CSCF. This time the answer of the HSS (UAA) contains the address of the already assigned S-CSCF and the I-CSCF forwards the request to this S-CSCF.

20

This verification uses a sequence number (SQN) that is shared between IMS terminal and HSS and contained within the encrypted AUTN string. 21 A bid-down attack may happen if an attacker removes e.g. the strongest security mechanism from the list.

Author: Dipl.-Ing. Franz Edler

page: 17 / 28

Part 4: IMS Identities, Authentication and Registration

REGISTER sip:homel.net SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z91iG4bK91i9ab Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net> Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>; expires=600000 Call-ID: 23fi571ju Authorization: Digest username="alice_private@homel.net", realm="home1.net",nonce="dcd98b7102dd2f0e8blld0i600bfb0c093", algorithm=AKAvl-MD5, uri="sip:homel.net", response=n6629fae49393a05397450978507c4efl" Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; ealg=aes-cbc; spi-c=909767; spi-s=421909; port-c:4444; port-s=5058 Require: sec-agree Proxy-Require: sec-agree Cseq: 2 REGISTER Supported: path Content-Length: 0

Figure 9: (11) REGISTER The final REGISTER request (15) received by the S-CSCF is shown in Figure 10 below.
REGISTER sip:homel.net SIP/2.0 Via: SIP/2.0/UDP icscfl.homel.net;branch=z9hG4bKealdof, Via: SIP/2.O/UDP pcscf1.visitedl.net;branch=z9hG4bKoh2qrz, Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 68 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net> Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>; expires=600000 Call-ID: 23fi571ju Authorization: Digest username="alice_private@homel.net", realm="home1.net",nonce=ndcd98b7102dd2f0e8blld0f600bfb0c093", algorithm=AKAvl-MD5,uri="sip:homel.net", response="6629fae49393a05397450978507c4efl", integrity-protected="yes" Require: path Supported: path Path: <sip:term@pcscf1.visitedl.net;lr> P-Visited-Network-ID: "Visited 1 Network" P-Charging-Vector: icid-value="W34h6dlg" Cseq: 2 REGISTER Content-Length: 0

Figure 10: (15) REGISTER

Author: Dipl.-Ing. Franz Edler

page: 18 / 28

Part 4: IMS Identities, Authentication and Registration The S-CSCF now validates the credentials (it compares the response parameter value with the expected result XRES of the associated authentication vector) and if this is successful the user is authenticated. The S-CSCF now informs the HSS that it is definitely allocated as the S-CSCF of the user and in addition requests the user profile in a diameter SAR (Server Assignment Request) message. The HSS returns the user profile in a diameter SAA (Server Assignment Answer) message. The user profile is an important piece of information associated with a Private User Identity. It includes, among other things, the list of all Public User Identities allocated to the Private User Identity and the subset of those which are automatically registered in the S-CSCF as a set of implicitly registered Public User Identities22. Additionally, the user profile also contains the initial filter criteria (iFC), which is the collection of triggers that determine when a SIP request is forwarded to an Application Server that will provide the service23. The S-CSCF now stores the URI contained in the Contact header field and the path URIs contained in the Path header field. The contact URI corresponds to the physical address where a user addressed by one of the related Public User Identities is reachable and the list of path URIs contains the route to that address. This list always includes the P-CSCF and sometimes also the I-CSCF. Later, when dialog initiating or stand alone requests to the user have to be forwarded, the S-CSCF will route these requests via the list of URIs included in the Path header field and the contact address in this order. Next the S-CSCF prepares the 200 OK response for the REGISTER request to be sent to the user. It includes a P-Associated-URI header field that contains all Public User Identities allowed to be used by the IMS terminal and which are implicitly registered. It also includes the Service-Route header field which contains the list of SIP servers that must be traversed in addition to the P-CSCF when the IMS terminal sends dialog initiating or standalone requests into the network. The Service-Route header field contains usually the S-CSCF and may additionally also contain an I-CSCF in case of topology hiding. Figure 11 shows the 200 OK response as it is received at the IMS terminal. We can see in this example that three additional Public User Identities may be used by the IMS terminal. Two pieces of routing information have been exchanged after the successful registration. The S-CSCF knows how it can reach the IMS terminal when it is addressed by one of the associated Public User identities (Path Header field). The IMS terminal knows which Route it must use for dialog initiating or standalone requests (P-CSCF plus Service Route header field). In addition two security associations are set up, a compression algorithm is negotiated, associated URIs are known by the terminal etc, a highly overloaded registration sequence using only two round trips!

22

A special case of an implicit set of Public User Identities is a wildcarded Public User Identity. It may be used to easily register a group of users behind a PBX. 23 Further details on the User Profile and the initial Filter Criterias are covered by another part of the course.

Author: Dipl.-Ing. Franz Edler

page: 19 / 28

Part 4: IMS Identities, Authentication and Registration

SIP/2.0 200 OK Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Path: <sip:term@pcscf1.visitedl.net;lr> Service-Route: <sip:orig@scscf1.homel.net;lr> From: <sip:alice@homel.net>;tag=s8732n To: <sip:alice@homel.net>;tag=409sp3 Call-ID: 23fi571ju Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>; expires=600000 Cseq: 2 REGISTER Date: Wed, 21 January 2004 18:19:20 GMT P-Associated-URI: <sip:alice-family@homel.net>, <sip:alice-business@homel.net>, <sip:+l-212-555-1234@homel.net;user=phone> Content-Length: 0

Figure 11: (20) 200 OK

3.3. OTHER REGISTRATION ALGORITHMS

The HTTP digest algorithm with authentication and key agreement (AKAv1-MD5) is the standard authentication method of 3GPP based networks, but there are simpler alternatives which might be used in other networks or during transition periods24. The IMS has to be regarded as an overlay network on an IP network (PS domain25 in mobile networks) and therefore in general two authentication and authorisation procedures are required: one for using the IP based transport network and one for the services provided by the IMS. The next two mechanisms presented below (bundled authentication) combine the two separate registrations mechanisms by re-using the authentication of the transport layer. The third mechanism mentioned below re-uses the combination of TLS and HTTP digest. 3.3.1. GPRS-IMS-BUNDLED AUTHENTICATION After successful establishment of the signalling association the GGSN sends information about the allocated IP address to the HSS and the S-CSCF checks if the received IP address during a registration is identical to the IP address provided by the GGSN previously. This means that the IMS relies on proper control of IP addresses used on the transport layer. This mechanism has some weakness regarding security but will be used during early IMS rollout. 3.3.2. NASS-IMS-BUNDLED AUTHENTICATION This mechanism is similar to the above mentioned GPRS-IMS bundled authentication but used in wireline (DSL based) networks. NASS (Network Attachment Subsystem) is a component od the wireline access network architecture. Instead of the IP-address as in GPRS networks a line identifier is used by the HSS. This line identifier is included in the P-Access-Network-Info header field (this time inserted by the PCSCF as a trusted network node) and checked by the S-CSCF against the requested identities during registration.
24 25

For details see 3GPP TS 33.203 Access Security for IP based services PS = Packet Switched in contrast to CS (Circuit Switched)

Author: Dipl.-Ing. Franz Edler

page: 20 / 28

Part 4: IMS Identities, Authentication and Registration 3.3.3. TLS CONNECTION ESTABLISHMENT Another access security mechanism for IMS may be based on a combination of TLS26 and HTTP Digest algorithm. TLS works with certificates but these are usually only available at the serverside and enable an authentication of the network by the client. The client is then authenticated by the network vie HTTP digest inside of the encrypted TLS channel. 3.3.4. SUMMARY ON ACCESS SECURITY ALGORITHMS As a summary it should be mentioned again that in regular 3GPP based networks27 only the strong security and authentication mechanism based on HTTP Digest and Authentication and Key Agreement must be used. All other methods may be used only in IMS based networks outside of 3GPP. The strong 3GPP authentication infrastructure is a very valuable asset of 3GPP operators. It can be leveraged to enable a further business opportunity: the selling of subscriber certificate based authentication services. 3GPP operators may sell the strong security and authentication infrastructure to third party application providers. More details on the generic use of the authentication architecture can be found in 3GPP TS 33.22028.

26 27

RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 Regular means outside of early IMS introductions 28 3GPP TS 33.220: Generic Authentication Architecture (GAA)

Author: Dipl.-Ing. Franz Edler

page: 21 / 28

Part 4: IMS Identities, Authentication and Registration

3.4. THE SUBSCRIPTION TO THE REGISTRATION EVENT STATE

In Figure 5 on page 13 we see that after the successful registration the P-CSCF and the IMSterminal independently subscribe to the registration event (messages 21 24 and 25 32). Why is this necessary? The basic RFC 3261 does not provide any possibility to instantly inform the user when it shuts down the service. The only mechanism is the registration timeout which is not appropriate due to the rather long delays. In carrier networks in particular mobile networks there are situations where the operator wants to clear the registration state of a terminal. The reason for that can be e.g. when the terminal is moving out of radio coverage or when the user requests the terminal to be locked because it was stolen. This problem can now be solved by the subscription to the registration event29. The IMS terminal therefore sends a SUBSCRIBE request for the registration state event into the network regarding the Public User Identity for which it registered just before. This request is handled by the S-CSCF as it has the role of the registrar server. The SUBSCRIBE request sent by the terminal is shown in Figure 12. It already uses the service route received during the registration within the Route header field and sends the SUBSCRIBE request via P-CSCF directly to the S-CSCF.
SUBSCRIBE sip:alice@homel.net SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 70 Route: <sip:pcscf1.visitedl.net:5058;lr;comp=sigcomp>, <sip:orig@scscfl.homel.net;lr> P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=d9211 To: <sip:alice@homel.net> Call-ID: b89rjhnedlrfjflslj40a222 Require: sec-agree Proxy-Require: sec-agree Cseq: 61 SUBSCRIBE Event: reg Expires: 600000 Accept: application/reginfo+xml Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; ealg=aes-cbc; spi-c=98765432; spi-s=909767;port-c=5057; port-s=5058 Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp> Content-Length: 0

Figure 12: (25) SUBSCRIBE to the registration event state The S-CSCF acts as a notifier and sends a NOTIFY request to the IMS terminal (see Figure 13). The XML part of the NOTIFY request contains the registration state for all three Public User Identities (including the implicitly registered identities) which have been included in the P-Associated-URI header field. You may observe in the event attribute of the contact tag the difference between the three registered identities: one is registered and two are created. This is reflects the implicit registration of two additional Public User Identities.
29

RFC 3680: A SIP Event Package for Registrations

Author: Dipl.-Ing. Franz Edler

page: 22 / 28

Part 4: IMS Identities, Authentication and Registration In the same way as the IMS terminal also the P-CSCF subscribes to the registration state. This subscription enables also the P-CSCF to be in sync about the Public-User Identities it has to care for. In addition to the IMS terminal and the P-CSCF also application servers may optionally subscribe to the registration event state.
NOTIFY sip:[1080::8:800:200C:417A]:5059;comp=sigcomp SIP/2.0 Via: SIP/2.O/UDP pcscfl.visitedl.net:5058;comp=sigcomp; branch=z9hG4bKoh2qrz Via: SIP/2.O/UDP scscfl.home1.net;branch=z9hG4bKslppO Max-Forwards: 69 Route: <sip:pcscf1.homel.net;lr> From: <sip:alice@homel.net>;tag=d9211 To: <sip:alice@homel.net>;tag=151170 Call-ID: b89rjhnedlrfjflslj40a222 Cseq: 42 NOTIFY Subscription-State: active;expires=600000 Event: reg Content-Type: application/reginfo+xml Contact: <sip:scscfl.homel.net> Content-Length: 873 <?xml version="1.0"?> <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="l" state="full"> <registration aor="sip:alice@homel.net" id="lla" state="active"> <contact id="542" state="active" event="registered" duration-registered="0"> <uri>sip: [1080::8:800:200C:417A]</uri> </contact> </registration> <registration aor="sip:alice-family@homel.net" id="llb" state="active"> <contact id="543" state="active" event="created" duration-registered="0"> <uri>sip:[1080::8:800:200C:417A]</uri> </contact> </registration> <registration aor="tel:+1-212-555-1234" id="llc" state="active"> <contact id="544" state="active" event="created" duration-registered="0"> <uri>sip:[1080::8:800:200C:417A]</uri> </contact> </registration> </reginfo>

Figure 13: (30) NOTIFY

Author: Dipl.-Ing. Franz Edler

page: 23 / 28

Part 4: IMS Identities, Authentication and Registration

3.5. A FEW REMARKS ON THE ROLE OF THE P-CSCF DURING REGISTRATION

The P-CSCF may be located in a different network in case of a roaming user. The P-CSCF is therefore no allowed to directly access the data repository (HSS) of the respective home network. The only chance to fulfil his role of a cotrolling border network element in IMS is by sniffing the necessary information during operation. In that way the P-CSCF stores several data dynamically for the registering users. These are e.g. The data in the Contact header field in combination with the security association. This enables the P-CSCF to reach an IMS terminal via the specific security association. The P-Associated-URIs: This enables the P-CSCF to check for valid identities used by the IMS terminal. The Service-Route header field: This enables the P-CSCF to check for valid Route header field used by the IMS terminal.

If some of the parameters in a request are incorrect or missing the P-CSCF has two choices: either reject the request or correct the parameters. Besides the specific tasks during the registration the P-CSCF additionally stores some data during operation e.g. the Record-Route and Route header field (the dialog route) and the Via header field to monitor correct routing behaviour of the IMS terminal.

Author: Dipl.-Ing. Franz Edler

page: 24 / 28

Part 4: IMS Identities, Authentication and Registration

4. EXERCISES AND QUESTIONS

After studying this part of the lecture you should be able to answer the following questions: Chapter 2: IMS Identities Explain the difference between Private and Public User Identities! What are they used for? Explain the interrelation of IMS subscription Private User Identity and Public User Identity! What is a Public Service Identity? What is the difference between a Public User Identity and a Public Service Identity? What are the two categories of PSIs? Explain the relationship between UICC and SIM, USIM and ISIM! Which data are typically stored on an UICC? Which data are stored in an ISIM application and explain the structure of these data! How can IMS users be addressed in the early IMS transition period?

Chapter 3.1: The simple SIP registration Describe the simple registration procedure defined in basic SIP! In a simple SIP based registration only the second REGSTER request contains an Authorization header field. Why does in an IMS registration the first REGISTER request already need an Authorization header field?

Chapter 3.2: The more complex IMS registration List the additional tasks accomplished during an IMS registration procedure in comparison to the simple SIP registration! What information is included in the P-Access-Network-Info header field? From the perspective of the IMS terminal: which SIP protocol extensions are required in an IMS registration and which extension is supported? Draw the message flow of an IMS registration showing SIP and diameter signalling! Which data from ISIM are mapped into which header fields and header field parameters in the REGISTRATION request of an IMS terminal? Which data is inserted by the P-CSCF into the REGISTER request? How does the P-CSCF know the address of an I-CSCF in the home network of the user? What is the role of the I-CSCF during IMS registration (1st and 2nd REGISTER transaction)? How does an I-CSCF select an S-CSCF for a user?

Author: Dipl.-Ing. Franz Edler

page: 25 / 28

Part 4: IMS Identities, Authentication and Registration Who inserts the integrity-protected parameter to the Authorization header field an what does it mean? Why does the P-CSCF increase the extension level for path from Supported to Required? What is the P-Visited-Network-ID header field used for? Which network node inserts the P-Charging-Vector and what is the characteristic of the icid value? Why does the S-CSCF need an authentication vector form HSS? What data are included exactly in an authentication vector? How are RAND and AUTN inserted into the 401 Unauthorized response? What happens to ik and ck parameters in the Authorization header field of the 401 Unauthorized response when it is sent to the IMS terminal? What are the Security-Client, Security-Server and Security-Verify header fields used for? What is the difference between the 1st and the 2nd REGISTER request sent from the IMS terminal from the security perspective? What is the difference in the diameter request of the I-CSCF between the 1st and the 2nd registration transaction? How is the home network verified by the IMS terminal? What information is exchanged between S-CSCF and HSS after successful verification of the credentials of the IMS terminal? What is the content of the user profile and to which identity is it linked? Which data are stored in the S-CSCF after successful registration of an IMS terminal? What is the Path header field used for and which network element needs it? What is the Service-Route header field used for and which network element needs it? Which network element may be optionally included in the Path and Service-Route header field and why? What information does the P-Associated-URI header field contain?

Chapter 3.3: Other registration algorithms Which kind of simplifications for authentication are used in mobile networks for early deployments and for wireline networks?

Which further business opportunity can be offered based on the strong authentication architecture of 3GPP networks.

Author: Dipl.-Ing. Franz Edler

page: 26 / 28

Part 4: IMS Identities, Authentication and Registration Chapter 3.4: The subscription to the Registration Event State Why is the subscription to the registration event state necessary? Which network elements subscribe to the registration event state? How many state entries does the XML part of the NOTIFY of the subscription to the registration event state contain and how do they differ?

Chapter 3.5: A few remarks on the role of the P-CSCF during registration Why is the P-CSCF not able to query the HSS? How doe the P-CSCF get the information it needs to fulfil its tasks? What data does the P-CSCF always check during operation? What are the choices for the P-CSCF when it detects incorrect parameters in a request?

Author: Dipl.-Ing. Franz Edler

page: 27 / 28

Part 4: IMS Identities, Authentication and Registration

5. REFERENCES
5.1. BOOKS ON SESSION INITIATION PROTOCOL
Henry Sinnreich und Alan B. Johnston: Internet Communcications Using SIP Wiley & Sons, ISBN-10: 0471776572 2nd edition: 2006 Alan B. Johnston: SIP Understanding the Session Initiation Protocol Artech House, ISBN 1-58053-168-7 2. Auflage November 2003

Henry Sinnreich, Alan B. Johnston und R. Sparks: SIP beyond VoIP VON Publishing LLC, www.vonmag.com ISBN: 0-9748130-0-1

5.2. BOOKS ON IP MULTIMEDIA SUBSYSTEM

The yellow book: G. Camarillo, M. Garcia-Martin: The 3G IP Multimedia Subsystem (IMS) Wiley & Sons, ISBN-10: 0470516623 ISBN-13: 978-0470516621 3rd Edition, 2009 The red book: M.Poikselka, G.Mayer, H. Khartabil: The IMS - IP Multimedia Concepts and Services Wiley & Sons, ISBN-10: 0470721960 ISBN-13: 978-0470721964 3rd Edition, 2009

Author: Dipl.-Ing. Franz Edler

page: 28 / 28