An SSO-Enabled Architecture for Beyond the IMS Domain Services Jean-Charles Gr´egoire and Salekul Islam Institut national de la recherche scientifique Montr´eal, Qu´ebec, Canada {gregoire, islam}@emt.inrs.ca
Abstract. The IP Multimedia Subsystem (IMS) is a converged framework for delivering voice, video and data communication services to mobile and fixed users. The present deployments of IMS, which assume a single operator for the access network, IMS core and application servers, restrict if and how users can access services beyond the IMS core network. Therefore, users are confined to a restricted business model and cannot experience a variety of services administered by a Service Provider (SP) other than the IMS core network. In this paper, a novel Single SignOn (SSO)-enabled architecture is proposed to extend the current IMS to offer users access to IMS–compatible services even beyond the IMS domain. The extended architecture, which is primarily dependent on the Security Assertion Markup Language (SAML) to transfer security information, reduces the burden of end users and SPs with a SSO feature. Two use cases are also presented to explain the federation building procedure through pseudonym identifiers and the Identity Provider–initiated SSO sequences.
1
Introduction
The IP Multimedia Subsystem (IMS) [3] is a Session Initiation Protocol (SIP) [11]-based generic architectural framework for delivering voice, video and data communication services to mobile and fixed users. IMS is becoming the de facto standard for real-time multimedia communication services for wireline and wireless operators alike. IMS focuses on the transparent delivery of multimedia and communication applications with SIP. It has successfully attracted the operators’ attention due to its foundation on two widely deployed technological building blocks: IP and SIP. IMS breaks the traditional isolated, dedicated, per-service architecture, and introduces the application-oriented horizontal solution. In the IMS service model, the IMS middle layer separates the service layer from the transport layer for greater flexibility. Hence, the benefit of IMS is to provide, through the middleware, access–independent, streamlined, common mechanisms for billing, authentication, security, QoS, etc. Therefore, in the IMS service model, common functions are reutilized rather than being (re–)implemented in multiple copies. The IMS layered approach provides the freedom of introducing new services very quickly in response to market dynamics to satisfy the demands
of the end users. However, with all these benefits, revenue-generating deployment of IMS-based services has not been widely experienced yet. Although third-party services are not precluded in the IMS specification (see Figure 4.2 of [3]), their detailed implementation means are not studied. In this paper, we address the limitations the existing single-operator IMS model inherits due to its operator-centric implementation. The existing model assumes a single operator for the access network, IMS core, user profile and application servers. In many cases, the operators fail to offer a popular service due to their own limitations (e.g. resource limitation) or for administrative reasons (e.g. broadcasting rights). Moreover, some Service Providers (SP) are not willing to outsource their control over the end users. Consequently, end users are deprived from the wide range of IMS-compatible applications hosted by the third-party SPs. It should be noted that, if the IMS architecture is extended to support applications beyond the operator’s IMS domain, end users would have to authenticate themselves and be authorized each time they connect to a new SP. In this paper, we propose the necessary extensions to the present IMS model to allow operators to offer to their users IMS services even beyond their own domain. This extended model would create opportunities for the IMS operator to form enriched partnerships with the SPs. Moreover, the proposed IMS model will provide Authentication, Authorization and Accounting (AAA) functionalities for a user who is using the beyond IMS domain services. It will also reduce the burden of both end users and SPs through a Single Sign-On (SSO) feature, accomplished through identity federation. The proposed model is primarily dependent on the use of the Security Assertion Markup Language (SAML) for assertions to transfer security information and develop security contexts between two domains. Two use cases are presented to explain the federation building procedure through pseudonym identifiers and the Identity Provider–initiated SSO sequences.
2
IP Multimedia Subsystem (IMS) and its limitations
The functional inter-domain architecture of NGN IMS is shown in Figure 1, where only the key components of the IMS core are highlighted. 2.1
IMS core and authentication
The core functional components for call control include different Call Session Control Functions (CSCF), such as Proxy CSCF (P-CSCF), Interrogation CSCF (I-CSCF) and Serving CSCF (S-CSCF). The P-CSCF is a SIP proxy that sits on the path of all signaling messages and ensures that SIP registration is passed to the correct home network or S-CSCF. The S-CSCF is a SIP server and the signaling plane’s central node; it registers users and provides services to them. The I-CSCF, a SIP proxy located at the edge of the home network, takes part in user roaming. The Home Subscriber Server (HSS) is the master user database and supports the IMS network entities in handling calls/sessions. It contains
End User
PDA
Transport Layer
SEG-B IP network
IP Phone
Service Layer
Home Network A
Visited Network B
Radio access network
Cell
Control Layer
S-CSCF
P-CSCF
IP connectivity access network
I-CSCF IMS Core B
AS1
SEG-A
HSS
AS2 AS3
IMS Core A
Laptop
Fig. 1. Functional architecture of Next-Generation Networking (NGN) IMS.
subscription-related information (i.e. user profiles), and performs authentication and authorization of the user. The I-CSCF and the S-CSCF use a AAA protocol, Diameter, for communicating with the HSS. IMS Authentication and Key Agreement (AKA) [2] is a challenge-response based authentication mechanism, which uses symmetric cryptography and provides mutual authentication between the IMS Services Identity Module (ISIM) of the UE and the home network. For identification, the ISIM uses the IP Multimedia Private Identity (IMPI), which has the form of a Network Access Identifier (NAI). The HSS of the home network and ISIM share a long-term key associated with the IMPI. On successful authentication of the UE, the S-CSCF registers the IM Public Identity (IMPU) of the UE, and the user is allowed to receive any service for which he has proper authorization. Moreover, the visited and home networks are connected through two Security Gateways (SEG), which establish a trusted link between the two networks following the Network Domain Security (NDS)/IP specification [1]. 2.2
Limitations of the present IMS model
Operators and service providers are keen to deploy IMS as it is expected to increase their Average Revenue Per User (ARPU) significantly. However, IMS deployment has been slow due to a number of challenges, a key one being the single-operator IMS original framework, which restricts the end users to the services their IMS operator offers. Therefore, the existing model fails to create mass user demand, which is the main driving force in a revenue generating business world. The present solution suppresses the emergence of other business models, such as virtual operators, or also limit the access to a large variety of applications and content. Another limitation is the lack of a user-centric approach. A new paradigm of user-centric service architecture, built around their needs and requirements, is getting popular among end users. In a competitive environment with choices between services, providers, devices and technologies — users are accustomed to
a level of control that was unimaginable a few years earlier. End users not only consume services but also share, recommend and subscribe to services according to their needs and preferences. Moreover, advanced users with their powerful UEs (e.g. iPhone, Smartphone, etc.), will definitely like to enjoy more freedom than the existing IMS model offers. IMS could be extended to provide excellent tools that allow the operator to remain in control of the network technology, but put the user in control of their service experience. It is worthwhile to mention that while designing an extended IMS model to support services beyond the IMS domain, one should consider the possibility of multiple authentication and authorization. In today’s IMS architecture, a user or UE has to complete at least two authentication steps before he receives services from the IMS core. A user (in a fixed or wireless network) or UE (in a cellular network) will be authenticated first by the access network. Next, using IMSAKA, the IMS core will authenticate the UE. If the services are administered by the same operator, no further authentication is required. However, to receive third-party services, the user will have to re-authenticate and re-authorize to each service provider.
3
Related work and goals of the proposed architecture
In this section, we have summarized work, from both telecom industries and academia, related to the deployment challenges we have identified. A security architecture for mobile operators has been proposed in [8], which administrate the IMS core to provide secure access to Web services for their IMS subscribers by making a partnership-oriented architecture between the operators and the Web service providers. In this architecture, SAML [7] incorporates federated identity, authentication and encryption. Thus, the mobile operators can increase their profits by sharing revenues with the content providers. However, this has been developed for Web services only, while IMS is targeting SIP-based services. IMS alone does not support the full spectrum of profitable services that content providers are delivering now and will continue to offer. Due to the rapid growth of different non-SIP-based applications, including IPTV, peer-to-peer streaming, Instant Messaging and Short Message Service (SMS), some content providers are not waiting for the IMS-based standards to support these applications. Ongoing standardization attempts are underway to integrate some of the popular non-SIP applications (e.g. IPTV services [5]) within the NGN architecture. The interworking of the Generic Bootstrapping Architecture (GBA) and the Liberty Alliance architecture provides simple SSO through identity federation. In [12], the GBA model is used to authenticate the UE before accessing multimedia applications offered by the IMS operator. An Authentication Proxy (AP) has been introduced, which also works as the Network Application Function (NAF) and implements a Transport Layer Security (TLS) tunnel between the UE and the AP. The Mobicome1 project provides an authentication mechanism–independent IMS architecture that ensures seamless access to different types of services (i.e. 1
http://telenor.projectcoordinator.net/∼mobicome
IMS, SIP and Web services) in a multi-access environment. The UE’s authentication device (e.g. SIM, ISIM and USIM) will be transparent to the IMS core. Thus, access network–agnostic solutions are being developed as part of the Mobicome project. Likewise, the SPICE2 , DAIDALOS3 and ScaleNet4 projects focus on the convergence of the telecommunications and the Internet based services. These projects are developing integrated heterogeneous network technologies that will allow network operators and SPs to offer profitable services, giving users access to a wide range of voice, data and multimedia services. These projects are not directly targeting the limitations of the present IMS model as described earlier; rather their work is restricted in the network and the transport layers, i.e. the communications between the UE and IMS core. However, extending the singleoperator IMS model to support beyond-IMS domain services—the primary goal of this paper—needs focus on user-tailored, secured communications between the IMS core and different SPs’ domains. We have set the following requirements for the proposed architecture: 1. A support for attractive, flexible and revenue-generating business models will be introduced by extending the existing IMS architecture, which would support different administrators for the access network, the IMS core, and the application servers. 2. The number of times a user needs to be authenticated should be minimized. Therefore, an SSO-enabled authentication architecture will be designed that will allow a user to access services from different SPs without re-authentication. 3. The proposed IMS extensions should not break the existing, applicationoriented horizontal IMS service model. Hence, all the benefits IMS provides, such as unified common mechanisms for user profile, QoS, signaling, billing, etc., will be applicable for the extended model as well. 4. There would be provisions for fine-grained access control or user authorization at the IMS core and the SPs’ domains. Moreover, The IMS core will ensure user privacy while sharing user information with the SP’s network.
4
Identity federation and Single Sign-On (SSO)
An SSO model authenticates the user only once for all the services he has been given rights to, and eliminates further authentication or sign-on when the user switches between services or applications during a particular session. There exist different ways to accomplish SSO, such as password synchronization, legacy SSO, Web Access Management (WAM), cross domain SSO and federated SSO. Among these, only the federated SSO has met widespread enterprise adoption. An identity federation correlates the different identities a user can have with 2 3 4
http://www.ist-spice.org/ http://www.ist-daidalos.org/ http://www.scalenet.de/
different SPs. An identity federation is a means to correlate the different identities a user can have with different SPs and to reduce the authentication burden. In a classical example, user John is registered as johndoe, jdoe on airlines reservation and car rental, respectively. The airlines reservation system, acting as an Identity Provider (IdP), creates a new pseudonym, johncar and links it with both his airline’s local ID (johndoe) and the car rental’s local ID (jdoe). Given that the existing identity federation standards (e.g. the Liberty Alliance Identity Federation Framework, Shibboleth and the Web Services Federation) are limited to Web services, we could not use them in our proposed architecture out of the box. However, most of the identity federation methods are built on top of SAML, which is a flexible and extensible protocol. 4.1
Use of SAML in SSO
SAML is an XML-based framework for transferring identity, authentication, attribute and authorization information between security domains, that is, between an IdP (a producer of assertions) and an SP (a consumer of assertions). SAML assertions are usually transmitted from an IdP to an SP and carry statements about a principal or user that an asserting party/IdP claims to be true. Before providing the SSO service, a federated identity for the user has to be established (either by dynamic account linking procedure or an off-line method) between the IdP and the SP. SAML assumes that the principal (often a user) has enrolled with at least one IdP, which is expected to provide local authentication services to the principal. Upon the user’s request, the IdP passes a SAML assertion to the SP. On the basis of this assertion, the SP makes an access control decision. 4.2
Benefits of SSO
An SSO feature between the IMS core and the SP networks through SAML brings many benefits for the proposed architecture. The existing IMS architecture is based on a converged service model, where the access network and the IMS core is owned and maintained by the same operator. Our proposed architecture will support the emergence of new business models, where the revenue will be shared between two (or more) parties (e.g. between the IMS core operator and the SP). In presence of such business models, an SSO feature will not only reduce the deployment and operational costs for the SPs, but also create many opportunities for the IMS core operator. The IMS core will be enhanced with centralized management of user information and roles, fine grained authorization and auditing, etc. Thus, it will be in position to advertise and provide a wide range of attractive services to the users from different competitive SPs, and to build revenue sharing relationships with SPs as well. The users will also benefit through improved user experiences (e.g. no password lists to carry, fast access to service, etc.). SSO can also improve privacy compliance by allowing the user to control what information is shared, or by limiting the amount of information shared.
End User
Acess
Service
Switching Service Provider Network
Home Network PDA
UIA
Radio access network IP network
Cell
IP Phone
Za
Mw
P-CSCF Gm
ID store Mw Cx
SEG-A S-CSCF
SEG-B ISC ID store
Cx
IP connectivity access network
HSS IMS Core
SIP-AS
SIP Server Cx PfS
USD
Laptop SIP
Diameter
Fig. 2. SSO Architecture for beyond the IMS Domain Services.
5
SSO-enabled Architecture for IMS Applications
The SSO-enabled authentication architecture for IMS applications is shown in Figure 2. In a federated identity model, the core IMS operator will take the role of the IdP. Therefore, we have introduced an entity named User Identity Asserter (UIA), inside the core IMS network. The IMS core, which maintains the user profile (i.e. the HSS) and authenticates the UE through IMS AKA, is the natural choice to implement the UIA. The UIA performs dual tasks: it works as an outgoing SIP entity and also serves as the IdP of the users. The UIA creates and forwards necessary assertions to the SP to confirm the authentication status of the users. A User Subscription Database (USD) has been introduced as an integral entity of the HSS to maintain the user’s subscription data for external SPs’ networks. The USD may also maintain other user related information, such as billing, presence, etc. The SP’s network is not necessarily an IMS-enabled network, and could be maintained by a third-party different from the IMS core operator. Given that the IMS core network primarily depends on SIP for signaling, the SP’s network must implement a SIP server entity to terminate the SIP calls forwarded by the UIA and thus perform tasks similar to the S-CSCF in inter-domain IMS (see Figure 1). Although the SIP Application Server (SIP-AS) is shown as the only service in Figure 2, the SP could deploy even a non-SIP service (e.g. IPTV [6]) if that service could be delivered through a session established by SIP signaling [5]. The home network and the service provider’s network will be connected through two SEGs, whose presence will be transparent to different entities that are located inside both networks. The SP maintains user profiles for each user through a Profile Server (PfS), which is located inside the SP’s network. Since the core IMS network uses SIP for UE registration and session establishment with the SP network, the UIA and the PfS will have to be SIP-enabled. As we propose to use SAML for assertions request, creation, response and verification, SAML encapsulation over SIP is required. The Internet Engineering Task Force (IETF) is in the process of specifying a SIP profile of SAML as well as a SAML SIP binding [9].
6
Building the Identity Federation
Establishing an identity federation is a prerequisite of an SSO-enabled architecture. An identity federation could be established through an out-of-band account linking or it could be achieved dynamically. In Figure 3, we have explained the identity federation use case of our proposed IMS model, which takes advantage of SAML V2.0’s ability to dynamically establish a federated identity. 6.1
Local User Identities at IdP and SP
In a federated-SSO model, a user needs local identities at both the IdP and the SP, and a federation associates these two local identities using a pseudonym identity. It is worthwhile to note that a local identity will never be recognized or used outside its local domain. In our proposed architecture, the UIA uses the public identity (IMPU) of a user as the local identity. A user has an IM Local Identity (IMLI) at each SP network, which is created during the subscription of the user at the SP. During the federation setup procedure (through dynamic account linking [7] or by any off-line method), the UIA creates a pseudonym identity for each SP, and associates the public identity (IMPU) with the SP through that pseudonym identity. In our model, we have named the pseudonym identity as IM Remote Identity (IMRI). Hence, the IMRI is the only identity recognized by both the UIA and the SP. The identity stores, maintained by the UIA and the SIP server, holds the tuple of the local identity (e.g. the IMPU or the IMLI), the pseudonym identifer (e.g. the IMRI) and the address of the other domain (e.g. the UIA or the SP). 6.2
Federation Building Procedure
In Figure 3, we show the federation building procedure. In the following, we explain it step-by-step: 1. The UE completes his authentication using IMS-AKA and the S-CSCF registers the IM Public Identity (IMPU) of the UE. 2. The UE sends a SIP INVITE message to the P-CSCF that carries the URI of the SP, the IMS Communication Service Identifier (ICSI), and the IMPI and the IMPU of the UE. 3. The P-CSCF sends a Cx-Query to the S-CSCF to confirm the registration status of the UE. The S-CSCF returns the registration status by sending a Cx-Response. If registration failure is received, the P-CSCF will not proceed. 4. The P-CSCF forwards the INVITE message to the UIA including the SP’s URI, the ICSI and the IMPU. The UIA looks up its ID store using the IMPU and understands that no federation had been established previously for this user’s subscription to the SP. The UIA forwards the INVITE message with the ICSI to the SP. 5. In response, the SIP server sends a SIP Redirect message, which includes the ICSI and a SAML AuthenRequest message requesting the UIA to provide an assertion using a pseudonym identifier.
(IMPU, IMRI, SP)
Home Network (IMS core) UE
P-CSCF
1. IMS AKA 2. INVITE (SP, ICSI, IMPI, IMPU)
S-CSCF
1. IMS AKA
HSS
(IMLI, IMRI, UIA)
ID store
ID store
UIA
SIP Server
Service Provider Network SIP-AS
PfS
1. IMS AKA
3.1 Cx-Query (IMPI, IMPU) 3.2 Cx-Resp (IMPI, IMPU) 4.1 INVITE (SP, ICSI, IMPU)
6.1 Cx-Query (IMPU, SP, ICSI) 6.2 Cx-Resp (authz, attribute)
8.1 Unauthorized 401 8.2 ACK (IMLI)
4.2 INVITE (ICSI) 5. Redirect 302 (ICSI) + SAML AuthnRequest
7. INVITE (IMRI) + [SAML Response (attribute)] 8.1 Unauthorized 401 (IMRI)
8.1 Unauthorized 401 (IMPU)
8.2 ACK (IMLI)
8.2 ACK (IMLI)
9. Update (IMLI, attribute)
10.1 Req-Prof (IMLI, ICSI) 10.2 Res-Prof (IMLI, ICSI)
11.1 Deliver Service 11.2 Service Delivery
Fig. 3. Building the Identity Federation using Pseudonym Identifiers.
6. The UIA sends a Cx-Query to the HSS to confirm the user’s subscription. The HSS checks the USD and returns the authorization status by sending a Cx-Response. If the UIA receives authorization failure, the UIA will not proceed. Optionally, the HSS may include attribute(s) of the user to forwarded the SP. The attributes might be cached by the UIA for future use. 7. The UIA creates a pseudonym identifier (i.e. IMRI) for the user’s subscription at the SP and associates the UE’s IMPU with the SP via IMRI. An entry with (IMPU, IMRI, SP) will be added to the UIA’s ID store. The UIA then builds a signed SAML assertion where the subject uses a pseudonym name identifier format. The assertion and the user’s attributes (if the UIA had received any from the HSS) are placed in a SAML Response message and sent to the SP network with a SIP INVITE message. 8. The SIP server validates the digital signature on the SAML Response and validates the SAML assertion. The SIP server looks up its ID store using the IMRI. If a previous federation had been established (because the name identifier maps to a local account) then it will go to step 9. Otherwise, the user will be challenged to provide his local credentials and identity (to which the IMRI should be assigned) with the SP. The SP sends a challenge (SIP Unauthorized 401 message) to the user using the HTTP digest authentication [10], which is used by a SIP server to authenticate a SIP client [11]. The user responds with a valid response (SIP ACK message with the IMLI) and
9.
10. 11.
12.
6.3
identifies his account at the SP as IMLI. Optionally the user might be asked whether he would like to federate the two accounts. By adding an entry with (IMLI, IMRI, UIA) to the SIP server’s ID store, the IMRI is stored and registered at the SIP server with the IMLI account and the name of the UIA. If any attribute had been received from UIA in step 7, the attribute(s) will be sent to the PfS to update the user profile. A local logon session is created for the IMLI and an access check is then made according to the access control policy of the SP. The SIP server may request service-specific profile at the PfS to establish whether the user IMLI has the correct authorization to receive the desired service. Following a successful access check, the requested service is returned to the user. Authorization and Accounting
User authorization and accounting/billing will be determined by a number of factors: the underlying business model, the service being delivered, access control and billing policies, etc. Hence, a Service Level Agreement (SLA) should be established between the home network and the SP network before delivering any service. In the proposed model, the revenue might be shared between two (or more) parties (e.g. between the IMS core operator and the SP). Therefore, a fine-grained or multi level authorization with different types of accounting will be more appropriate. Consider a scenario where an IMS user subscribes to a Videoon-Demand (VoD) service from a third-party SP for one month: the SP and the IMS core should have some revenue–sharing SLA. For example, the user will pay a fixed amount to the IMS operator, while the user will pay the SP for each VoD session he orders. In this example, the USD and the PfS maintain different types of access control and accounting information for the user. Moreover, the IMS core and the SP will authorize and charge the user differently. The IMS core will forward the user’s VoD requests to the SP after matching the identity and the subscription of the user. The SP will provide the VoD session after checking the category of the requested VoD session. In case of accounting, the IMS core is not interested in receiving any user session–specific usage information, and the SP will not send any accounting information at the end of a VoD session. However, the SP will keep track of such information to charge the user. 6.4
Ensuring User Privacy and Consent
The proposed model has provisions for ensuring user privacy and consent while building the identity federation. The HSS will respond to SP network queries that are strictly limited to the user’s subscription. The domain of such queries should be defined under the SLA between the IMS core and the SP network. Moreover, by using pseudo identifier for account linking, the user’s real identity (e.g. name, email address, etc.) is never revealed to the SP network and the user’s anonymity could be achieved. Moreover, an identity federation will only be built
(IMPU, IMRI, SP)
Home Network (IMS core) UE
P-CSCF
1. IMS AKA
S-CSCF
1. IMS AKA
2. INVITE (SP, ICSI, IMPI, IMPU)
(IMLI, IMRI, UIA)
Service Provider Network
ID store
ID store
UIA
SIP Server
HSS
SIP-AS
PfS
1. IMS AKA
3.1 Cx-Query (IMPI, IMPU) 3.2 Cx-Resp (IMPI, IMPU) 4. INVITE (SP, ICSI, IMPU)
5. INVITE (ICSI, IMRI, SAML Artf)
6.1 HTTP GET (SAML Assert)
6.2 HTTP 200 OK + SAML Assert
7.1 Req-Prof (IMLI, ICSI) 7.2 Resp-Prof (IMLI, ICSI) 8.1 Deliver Service
8.2 Service Delivery
Fig. 4. IdP-initiated SSO Sequence for IMS Applications.
with proper user consent. Therefore, before sending the SAML Response in step 7 (shown in Figure 3), either the HSS or the UIA should communicate with the user and request his consent (this step is not shown in Figure 3). 6.5
SSO Operational Sequence
The operational sequence for the SSO-enabled architecture is shown in Figure 4 by presenting a UIA (IdP)-initiated use case. However, the proposed architecture also supports SP-initiated SSO—it is assumed that the UIA and the SP have already built the federation using the procedure explained in section 6. The first 4 steps of Figures 4 and 3 are same and were explained in section 6. Hence, we explain the remaining steps only in the following: 5. The UIA looks up in its ID store and finds that the IMRI was previously associated with the IMPU. It sends to the SP network an INVITE message that includes the ICSI, the IMRI and a SAML Artifact (a SAML-Info header [9]). 6. The SIP server dereferences the HTTP-based SAML URI Reference found in the SAML-Info header, and receives the SAML Assertion from the UIA using HTTP messages. The SIP server must verify the Assertion. If the verification fails, the procedure will not go further. Otherwise, the SIP server looks up its ID store using the IMRI and retrieves the local identity of the user, i.e. the IMLI. 7. A local logon session is created for the user IMLI and an access check is made according to the access control policy of the SP. The SIP server may request a service-specific profile at the PfS to establish whether the user IMLI has the correct authorization to receive the requested service. In addition,
the SIP server may also send Attribute Request messages to the UIA to communicate with the HSS and send back an Attribute Response. 8. If the access check passes, the desired service is returned to the user.
7
Conclusion and Future Work
We have presented an architecture offering alternatives for third-party supplied services in IMS. The SSO-enabled model introduces secure and scalable identity management and benefits all three parties: users, SPs and network operators. Users will have access to a broader range of IMS-supported services; SPs can leverage and reduce the costs related to the management of identity information and the operators may take the added role of IdP, as well as seeing new forms of business partnership emerge. In future work, we would like to further explore the security properties of the federation building and the SSO sequences use cases by using an industrial-strength security protocol validation tool (e.g. AVISPA [4]). Finally, we will implement our model by extending the available open source implementations of IMS and identity federation. Acknowledgements This work described here is part of a deliverable to a project funded by Bell Canada through its Bell University Laboratories R&D program.
References 1. “3GPP; Technical Specification Group Services and System Aspects; 3G Security; Network domain security; IP network layer security”. TS 33.210 V8.1.0, Oct. 2008. 2. “3GPP; Technical Specification Group Services and System Aspects; Access security for IP-based services”. TS 33.203 V8.3.0, Jun. 2008. 3. “3GPP: Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS), Stage 2”. TS 23.228 V8.5.0, Jun. 2008. 4. Automated Validation of Internet Security Protocols and Applications (AVISPA), http://www.avispa-project.org. 5. “Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IPTV functions supported by the IMS subsystem”. ETSI TS 182 027 Ver. 3.0.2, Jul. 2008. 6. “IPTV Architecture”. ITU-T IPTV Focus Group, FG IPTV-DOC-0181, 2007. 7. “Security Assertion Markup Language (SAML) V2.0 Technical Overview”. OASIS Committee Draft 02, Mar. 2008. 8. A. Balyan, et al. “Security architecture for IP-based multi-service networks”. Bell Labs Technical Journal, 11(1):59–78, 2006. 9. H. Tschofenig, et al. “SIP SAML Profile and Binding”. Internet Draft, Work in progress, 2009. 10. J. Franks, et al. “HTTP Authentication: Basic and Digest Access Authentication”. RFC 2617, June 1999. 11. J. Rosenberg, et al. “SIP: Session Initiation Protocol”. RFC 3261, June 2002. 12. M. Sher and T. Magedanz. “Secure Access to IP Multimedia Services Using Generic Bootstrapping Architecture (GBA) for 3G and Beyond Mobile Networks”. In Proc. of the 2nd ACM Q2SWinet, pages 17–24, 2006.
