Professional Documents
Culture Documents
LECTURE NOTE 4
Version: Datum: 2.2 12.03.2010
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
page: 2 / 28
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.
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/
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.
page: 4 / 28
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.
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
page: 5 / 28
Service Profile 1
Service Profile 2
Public User Identity 3 IMS Subscription Public User Identity 4 Implicitly Registered ID Set 2
Service Profile 3
Service Profile 4
Figure 1: Relationship between Private and Public User Identities (TS 23.228)
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).
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
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 Public User Identity
Long-term Secret
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.
page: 9 / 28
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
page: 10 / 28
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)
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
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
page: 13 / 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 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
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.
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.
page: 16 / 28
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.
page: 17 / 28
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
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.
page: 19 / 28
For details see 3GPP TS 33.203 Access Security for IP based services PS = Packet Switched in contrast to CS (Circuit Switched)
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)
page: 21 / 28
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
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>
page: 23 / 28
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.
page: 24 / 28
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?
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.
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?
page: 27 / 28
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
page: 28 / 28