IMS-Part4-IMS Identities & Registration

Embed Size (px)

Citation preview

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    1/28

    Study Program

    Master Telecommunications and Internet Technologies

    Course

    Application Prototyping

    LECTURE NOTE 4

    Version: 2.2

    Datum: 12.03.2010

    IP MULTIMEDIA

    SUBSYSTEM (IMS)Identities, Authentication and

    Registration

    Dipl.-Ing. Franz Edler

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    2/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 2 / 28

    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

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    3/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 3 / 28

    1. OVERVIEW1.1.CONTENT OF THE COURSEThe 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 willreplace 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 COURSEThe course actually comprises the following parts:

    1. IMS Overview and Standards

    2. Basic Technologies: SIP recap and new protocols and extensions

    3. IMS network architecture4. IMS Identities, Authentication and Registration5. 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 EXERCISESThe 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

    1TDM = Time Division Multiplex

    2SIP = Session Initiation Protocol, RFC 3261

    3I strongly recommend the Tech-Invite portal http://www.tech-invite.com/

    4Open IMS Core project of Fraunhofer Fokus http://www.openimscore.org/

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    4/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 4 / 28

    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 over-

    come 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 EXERCISESAt 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 AUDIENCEThe 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    5/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 5 / 28

    2.IMS IDENTITIESEvery 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:[email protected] 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.

    5Details can be found in TS 23.003: Numbering, addressing and identification

    6To avoid confusion: also the private identity in this example is addressed by a Public User Identity!

    7The 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 Exchange9

    RFC 4282: The Network Access Identifier

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    6/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 6 / 28

    2.3.RELATIONSHIP BETWEEN PRIVATE AND PUBLIC USER IDENTITIESThe 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 ISIMapplication 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 oneterminal.

    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.

    ImplicitlyRegistered ID

    Set 3

    PrivateUser Identity 1

    PublicUser Identity 1

    PublicUser Identity 2

    PublicUser Identity 3

    ImplicitlyRegistered ID

    Set 1

    PrivateUser Identity 2

    PublicUser Identity 4

    PublicUser Identity 5

    PublicUser Identity 6

    Implicitly

    Registered IDSet 2

    ServiceProfile 1

    ServiceProfile 2

    ServiceProfile 3

    ServiceProfile 4

    IMS

    Subscription

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

    2.4.THE PUBLIC SERVICE IDENTITYBesides 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    7/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 7 / 28

    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!.*[email protected]" whereby the ! is a delimiter forthe 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 2

    ndgeneration

    (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.IMSSUBSCRIBER 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.

    10Details on iFC are covered in part 6 of the lecture.

    113GPP TS 31.103: Characteristics of the IP Multimedia Services Identity Module (ISIM) application

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    8/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 8 / 28

    Figure 2 depicts the structure of the ISIM application. The relevant parameters stored in ISIM

    are as follows:

    Private User Identity: ISIM stores the Private User Identity allocated to the user. There

    can only be one Private User Identity stored in ISIM.

    Public User Identity: 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 orreceives 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

    Public User Identity

    Public User Identity

    1n

    Home Network Domain URI

    Long-term Secret

    . . .

    Figure 2: Structure of an ISIM application

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    9/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 9 / 28

    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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    10/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 10 / 28

    3.IMS REGISTRATION3.1.THE SIMPLE SIP REGISTRATIONSIP 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.

    12Remember: 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

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    11/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 11 / 28

    3.2.THE MORE COMPLEX IMS REGISTRATIONWithin 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 userauthenticates the network.

    An encryption and an integrity key are provided to protect the first hop (from IMS terminalto the P-CSCF).

    A security mechanism is negotiated between the IMS terminal and the P-CSCF. Thenegotiation 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 preloadedsignalling Route (Service-Route header).

    The path is created and stored by the S-CSCF by which the S-CSCF always knows howthe IMS terminal can be reached (Path header).

    In case the P-CSCF is in a visited network the home network verifies if a valid roamingagreement exists and if the user is allowed to roam.

    The home network informs the user about additional Public User Identities which the usermay 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.

    13RFC 2617: HTTP Authentication

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

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    12/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 12 / 28

    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 thatsignalling compression is supported by the IMS terminal.

    The P-Access-Network-Info header field carries information about access technology andlocation.

    The expires value at the Contact header field is rather high (600000 seconds which is about7 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 containsthe 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: ;tag=s8732n

    To:

    Contact: ;expires=600000

    Call-ID: 23fi571ju

    Authorization: Digest username="[email protected]",

    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

    15RFC 3329: Security Mechanism Agreement for SIP

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    13/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 13 / 28

    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 theresponsible network (request URI of the REGISTER request)

    A Public User Identity is used as Address-of-Record in To and From header field. Incase 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 parametervalue in the Authorization header.

    IMS Terminal P-CSCF I-CSCF HSS S-CSCF

    (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

    (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

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    14/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 14 / 28

    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 islocated and sends the REGISTER,

    Path header-field with its own URI to request the home network of the user to send allrequests 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 theyoften 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 theIMS terminal?

    16This 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-to-

    live).17

    The capabilities are not defined in the standard only the selection mechanism. The capabilities have a numericvalue and their semantics are defined by the network operator.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    15/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 15 / 28

    Of course we now have three VIA-header fields (only the first has the comp=sigcompparameter)

    The Authorization header field has got the additional parameter integrity-protected addedby 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 Pathheader field, which contains the address of the P-CSCF (only

    18). 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 thatthe 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: ;tag=s8732n

    To:

    Contact: ;expires=600000

    Call-ID: 23fi571ju

    Authorization: Digest username="[email protected]",

    realm="homel.net", nonce="",uri="sip:home1.net",response="",

    integrity-protected="no"

    Require: path

    Supported: path

    Path:

    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. TheS-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

    18In 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 itneeds to authenticate the user again.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    16/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 16 / 28

    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: ;tag=s8732n

    To: ;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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    17/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 17 / 28

    SIP/2.0 401 Unauthorized

    Via: SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp;

    branch=z9hG4bK9h9ab

    From: ;tag=s8732n

    To: ;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 onthe 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 firstREGISTER 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.

    20This 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    18/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 18 / 28

    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: ;tag=s8732n

    To:

    Contact: ;

    expires=600000

    Call-ID: 23fi571ju

    Authorization: Digest username="[email protected]",

    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=C359A3913B20EFrom: ;tag=s8732n

    To:

    Contact: ;

    expires=600000

    Call-ID: 23fi571ju

    Authorization: Digest username="[email protected]",

    realm="home1.net",nonce=ndcd98b7102dd2f0e8blld0f600bfb0c093",

    algorithm=AKAvl-MD5,uri="sip:homel.net",

    response="6629fae49393a05397450978507c4efl",

    integrity-protected="yes"

    Require: path

    Supported: path

    Path: P-Visited-Network-ID: "Visited 1 Network"

    P-Charging-Vector: icid-value="W34h6dlg"

    Cseq: 2 REGISTER

    Content-Length: 0

    Figure 10: (15) REGISTER

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    19/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 19 / 28

    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 theassociated 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!

    22A 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    20/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 20 / 28

    SIP/2.0 200 OK

    Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp;

    branch=z9hG4bK9h9ab

    Path:

    Service-Route:

    From: ;tag=s8732n

    To: ;tag=409sp3

    Call-ID: 23fi571ju

    Contact: ;

    expires=600000

    Cseq: 2 REGISTER

    Date: Wed, 21 January 2004 18:19:20 GMT

    P-Associated-URI: ,

    ,

    Content-Length: 0

    Figure 11: (20) 200 OK

    3.3.OTHER REGISTRATION ALGORITHMSThe 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 AUTHENTICATIONAfter 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 AUTHENTICATIONThis 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 P-

    CSCF as a trusted network node) and checked by the S-CSCF against the requested identities

    during registration.

    24For details see 3GPP TS 33.203 Access Security for IP based services

    25PS = Packet Switched in contrast to CS (Circuit Switched)

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    21/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 21 / 28

    3.3.3.TLSCONNECTION ESTABLISHMENTAnother access security mechanism for IMS may be based on a combination of TLS

    26and HTTP

    Digest algorithm. TLS works with certificates but these are usually only available at the server-

    side 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 ALGORITHMSAs 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

    .

    26RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2

    27Regular means outside of early IMS introductions

    283GPP TS 33.220: Generic Authentication Architecture (GAA)

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    22/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 22 / 28

    3.4.THE SUBSCRIPTION TO THE REGISTRATION EVENT STATEIn Figure 5 on page 13 we see that after the successful registration the P-CSCF and the IMS-

    terminal 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 shutsdown 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 toclear 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-CSCFdirectly to the S-CSCF.

    SUBSCRIBE sip:[email protected] SIP/2.0

    Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp;

    branch=z9hG4bK9h9ab

    Max-Forwards: 70

    Route: ,

    P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E

    From: ;tag=d9211

    To:

    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:

    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.

    29RFC 3680: A SIP Event Package for Registrations

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    23/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 23 / 28

    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:

    From: ;tag=d9211

    To: ;tag=151170

    Call-ID: b89rjhnedlrfjflslj40a222

    Cseq: 42 NOTIFY

    Subscription-State: active;expires=600000

    Event: reg

    Content-Type: application/reginfo+xml

    Contact:

    Content-Length: 873

    sip: [1080::8:800:200C:417A]

    sip:[1080::8:800:200C:417A]

    sip:[1080::8:800:200C:417A]

    Figure 13: (30) NOTIFY

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    24/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 24 / 28

    3.5.A FEW REMARKS ON THE ROLE OF THE P-CSCF DURING REGISTRATIONThe 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. Thisenables 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 theIMS terminal.

    The Service-Route header field: This enables the P-CSCF to check for valid Routeheader 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 dataduring 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    25/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 25 / 28

    4.EXERCISES AND QUESTIONSAfter 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 UserIdentity!

    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 anAuthorization 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 incomparison 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 inan 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 parametersin 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 REGISTERtransaction)?

    How does an I-CSCF select an S-CSCF for a user?

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    26/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 26 / 28

    Who inserts the integrity-protected parameter to the Authorization header field an whatdoes it mean?

    Why does the P-CSCF increase the extension level for path from Supported toRequired?

    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 theicid 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 the401 Unauthorized response when it is sent to the IMS terminal?

    What are the Security-Client, Security-Server and Security-Verify header fieldsused for?

    What is the difference between the 1st and the 2nd REGISTER request sent from the IMSterminal from the security perspective?

    What is the difference in the diameter request of the I-CSCF between the 1st and the 2ndregistration transaction?

    How is the home network verified by the IMS terminal?

    What information is exchanged between S-CSCF and HSS after successful verification ofthe 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-Routeheader 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.

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    27/28

    Part 4: IMS Identities, Authentication and Registration

    Author: Dipl.-Ing. Franz Edler page: 27 / 28

    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?

  • 7/30/2019 IMS-Part4-IMS Identities & Registration

    28/28

    Part 4: IMS Identities, Authentication and Registration

    5.REFERENCES5.1.BOOKS ON SESSION INITIATION PROTOCOLHenry 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 IPMULTIMEDIA SUBSYSTEMThe 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