• No results found

Design and Implementation of a HTTP-Based Authentication Infrastructure for Service Access to the IP Multimedia Subsystem.

N/A
N/A
Protected

Academic year: 2021

Share "Design and Implementation of a HTTP-Based Authentication Infrastructure for Service Access to the IP Multimedia Subsystem."

Copied!
168
0
0

Loading.... (view fulltext now)

Full text

(1)

Kommunikationssysteme

Design and Implementation of a HTTP-Based

Authentication Infrastructure for Service Access to

the IP Multimedia Subsystem

Diplomarbeit

Sebastian Wahle

Berlin, 25. Januar 2007

Fakult¨at IV - Elektrotechnik und Informatik

Lehrstuhl Architekturen der Vermittlungsknoten (AV) Franklinstr. 28-29, D-10587 Berlin

Supervisor: Prof. Dr. Ing. habil Thomas Magedanz Assistant supervisor: Dipl. Wi-Ing. Peter Weik Matrikelnummer: 203593

(2)
(3)

Kommunikationssysteme

Design and Implementation of a HTTP-Based

Authentication Infrastructure for Service Access to

the IP Multimedia Subsystem

Diplomarbeit

Sebastian Wahle

Berlin, 25. Januar 2007

(4)

Hiermit versichere ich, Sebastian Wahle, an Eidesstatt, die vorliegende Arbeit ohne unerlaubte Hilfsmittel, selbstst¨andig, eigenh¨andig und unter ausschließlicher Verwendung der angegebenen Literatur erstellt zu haben.

Berlin, 24. Januar 2007

(5)

Ich danke Maria Hommeyer, meiner zuk¨unftigen Frau, f¨ur ihre Liebe.

Ich danke weiterhin Prof. Dr. Ing. habil Thomas Magedanz und Dipl. Wi-Ing. Peter Weik f¨ur die M¨oglichkeit, diese Arbeit zu schreiben und die gute

(6)
(7)

This thesis describes how HTTP access to IP Multimedia Subsystem (IMS) ser-vices can be secured (authentication, authorization and channel security) reusing user identity information and security values existing in the central IMS network database, the Home Subscriber Server (HSS). The 3rd Generation Partnership Project (3GPP) proposed and specified the Generic Bootstrapping Architecture (GBA), which is used to bootstrap a security association between a client and a server and which has been the fundamental design pattern for the infrastruc-ture layout. The GBA consist mainly of two server components: a Bootstrapping Server Function (BSF) and a Network Application Function (NAF). On the high-est layer, it connects to the IMS via the Diameter protocol and the HTTP protocol. Furthermore, this document outlines what the IMS is and why its deployment is beneficial for operators and end users. A broad overview of the specification and standardization landscape is given as well as the interconnection between existing standards that are relevant for the GBA.

This written thesis is accompanied by a software implementation of more than 15000 lines of code that have been written in Java. The authentication server components like BSF and NAF as well as extensions such as a HTTP to IMS gateway (HTTP2IMS GW) and a demonstration client have been implemented. A twofold approach has been chosen for the implementation. While a 3GPP-compliant method of realizing HTTP-based IMS service access has been imple-mented, the standardized infrastructure has been further extended beyond the specifications, reusing some standardized elements, in order to support not only GBA-capable IMS clients, but also standard web browsers. This is useful as GBA-capable IMS clients are currently not publicly available (in contrast to web browsers).

(8)
(9)

Abstract vii

List of Figures xiii

List of Tables xv

1 Introduction 1

1.1 Motivation . . . 2

1.2 Scope . . . 3

1.3 Structural Overview . . . 4

2 Access to IMS Services 7 2.1 What Is the IMS and Why Is It Needed? . . . 7

2.2 Service Deployment Based on a Layered Architecture . . . 9

2.3 The IMS Architecture and Its Core Components . . . 12

2.4 The Hypertext Transfer Protocol . . . 14

2.5 The Generic Bootstrapping Architecture . . . 15

2.6 The Standardization Organizations and Specification Impact . . . 21

2.6.1 Third Generation Partnership Project. . . 22

2.6.2 Third Generation Partnership Project 2 . . . 25

2.6.3 ETSI / TISPAN . . . 26

2.6.4 Cable Television Laboratories . . . 28

2.6.5 Open Mobile Alliance. . . 29

2.6.6 Advances to IP Multimedia Subsystem (A-IMS) . . . 31

2.7 Summary . . . 34

3 Infrastructure Design and Requirements 35 3.1 2G GBA, GBA ME and GBA U. . . 35

3.2 The Diameter Protocol . . . 36

3.3 Standard GBA With Mobile Equipment . . . 38

3.3.1 The Bootstrapping Procedure . . . 39

3.3.2 Usage of the Bootstrapped Security Association on UE-NAF Communication . . . 44

(10)

3.5 The NAF Authentication Proxy . . . 49

3.6 Interface Ut Replacement and the OMA Aggregation Proxy Inter-face XDM-3 . . . 54

3.7 The GBA User Security Settings . . . 56

3.8 Summary . . . 59

4 Software Implementation 61 4.1 GBA Problems and This Thesis’s Solutions. . . 61

4.1.1 The Need for a UICC/ISIM . . . 61

4.1.2 The User Identifier Problem . . . 64

4.1.3 Cross Domain Single Sign-On or the Common Domain Cookie Problem . . . 66

4.1.4 GBA-Enabled Clients. . . 67

4.1.5 Service Access Configuration Based on User Identities . . . 67

4.2 The Bootstrapping Server Function . . . 68

4.2.1 Building and Deployment of the BSF Server . . . 70

4.2.2 Configuration of the BSF Server . . . 72

4.2.3 The Diameter Stack . . . 72

4.2.4 Zh Interface . . . 73

4.2.5 Zn Interface . . . 74

4.2.6 Ub Interface . . . 75

4.2.7 Ub* Interface . . . 76

4.3 The Network Application Function . . . 80

4.3.1 Building, Configuration, and Deployment of the NAF Server 82 4.3.2 The Authentication Proxy . . . 83

4.3.3 The PKI Portal . . . 84

4.3.4 Zn Interface . . . 87

4.3.5 Ua Interface . . . 87

4.3.6 Ua* Interface . . . 88

4.4 The Demonstration Client Application . . . 89

4.4.1 The Client Ub Interface . . . 90

4.4.2 The Client Ua Interface . . . 92

4.5 Summary . . . 94

5 Software Validation Within the FOKUS Open IMS Playground 95 5.1 SSO for All AP-Connected IMS Services . . . 95

5.2 Interaction With the FHoSS . . . 97

5.3 Interface Ua and Ub Validation . . . 100

5.4 The O2 FMC Portal Service . . . 100

5.5 The Smart Messenger Service . . . 102

(11)

6 Summary and Outlook 107 A German Summary 109 B Diameter Commands 111 B.1 Multimedia-Auth-Request (MAR) . . . 111 B.2 Multimedia-Auth-Answer (MAA) . . . 112 B.3 Bootstrapping-Info-Request (BIR) . . . 112 B.4 Bootstrapping-Info-Answer (BIA) . . . 113

C Specification of the Key Derivation Procedure 115 C.1 Introduction . . . 115

C.2 Generic Key Derivation Function . . . 115

C.2.1 Input Parameter Encoding . . . 116

C.3 NAF Specific Key Derivation in GBA and GBA U . . . 117

D GBA-UserSecSettings XML definition 119 E Sample Configuration Files 123 E.1 The BSF Configuration File . . . 123

E.2 The NAF Configuration File . . . 124

E.3 The GBA Demonstration Client Configuration File . . . 126

E.4 The Diameter Peer Configuration File. . . 128

E.5 The HTTP2IMS GW User Provisioning File . . . 129

F Related Work and Patents 131

Bibliography xvii

(12)
(13)

1.1 The Generic Bootstrapping Architecture . . . 4

2.1 The NGN Layered Architecture . . . 10

2.2 The Simplified IMS Architecture. . . 12

2.3 The Generic Bootstrapping Architecture . . . 16

2.4 The GBA and IMS Architecture Interpreted as NGN Layers . . . 16

2.5 The General Bootstrapping procedure. . . 18

2.6 The TISPAN NGN Security Architecture [ETSI187003] . . . 27

2.7 The A-IMS Architecture Overview [AIMS] . . . 33

3.1 The Diameter Message Format [RFC3588] . . . 37

3.2 The Bootstrapping Procedure . . . 39

3.3 The Bootstrapping Message Flow [TS24.109], modified . . . 39

3.4 Accessing the AS via the NAF . . . 45

3.5 HTTP Digest Authentication With Bootstrapped Security Associ-ation [TS24.109], modified . . . 46

3.6 Fixed Line GBA Access Without UICC/ISIM With the HTTP to IMS Gateway . . . 48

3.7 The Authentication Proxy . . . 50

3.8 Service Access via HTTP2IMS GW and AP Without GBA-Enabled Device . . . 51

3.9 Functional Architecture for Reference Point Ut [TS23.002] . . . . 54

3.10 The NAF as AP Replacing Interface Ut [TS33.222] . . . 54

3.11 XML Document Management Architecture [OMAxdm] . . . 55

3.12 Graphical Representation of the GUSS . . . 57

4.1 USB Smart Card Reader for SIM/UICC cards . . . 63

4.2 The Logical Structure of the BSF Server . . . 69

4.3 The Zh Diameter Message Exchange . . . 74

4.4 The Zn Diameter Message Exchange . . . 75

4.5 The Ub* Interface. . . 76

4.6 The HTTP2IMS GW Login Page as a Screenshot . . . 77

4.7 The UID Selection at the HTTP2IMSGW as a Screenshot . . . . 78

(14)

4.9 The Modified GBA Infrastructure for PKI Support and Certificate

Issuing . . . 84

4.10 The Ua/Ub Client GUI . . . 90

4.11 The Client GUI After a Successful Ub Interface Run With the BSF 91 4.12 The Client GUI After a Successful Ub Interface Run . . . 93

5.1 The Validation Setup Within the FOKUS Open IMS Playground 96 5.2 The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-Request . . . 97

5.3 The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-Answer. . . 98

5.4 The FHoSS GUSS Provisioning Website . . . 99

5.5 The O2 FMC Portal Welcome Page Screenshot . . . 101

5.6 The O2 FMC Portal Offered Web Mailbox Service . . . 102

5.7 The FOKUS Open IMS Playground Smart Messenger Demo Screen-shoot . . . 103

5.8 Wireshark Trace of AP - XDMS Contact List Retrieval Communi-cation . . . 105

(15)

4.1 Mapping of Functional Components to Java Projects and Classes of the Implementation . . . 70

4.2 Third Party Libraries Used by the BSF Implementation . . . 71

4.3 Third Party Libraries Used by the NAF Implementation . . . 81

4.4 Mapping of Functional Components to the Java Classes and Projects of the Implementation . . . 81

(16)
(17)

Introduction

Due to the variety of communication and access network technologies, nowadays services need to be provided ”seamlessly” on top of different network technolo-gies. The telecommunications sector is facing a shift from the current concept of ”anywhere, anytime” to a new paradigm of ”any network, any device”. In addi-tion, relevant content and context become increasingly important, while access in a secure and trustworthy manner is expected by end users. This influences cur-rent network architectures, while convergence across services, media, and access technologies has implications for identity management, privacy and security. The IP Multimedia Subsystem (IMS), defined by the 3rd Generation Partner-ship Projects (3GPP and 3GPP2), was developed to address network convergence challenges and end-user requirements. The IMS is the unified telecommunica-tion industry approach toward an all-IP network architecture that merges the paradigms and technologies of the Internet with the cellular and fixed telecom-munication worlds. It aims at creating a reference service delivery platform for provisioning IP multimedia services in a reliable, secure, and controllable manner and was also adopted as the basis of the Next Generation Network (NGN) archi-tecture specified by TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks).

As part of the IMS specification, 3GPP defined a Generic Authentication Archi-tecture (GAA) and the Generic Bootstrapping ArchiArchi-tecture (GBA) to address security issues, especially authentication. The GBA is used to bootstrap a short term security association between a client and a server. This is done based on a long term security association, that is stored in a tamper resistant module in the client, as well as at the server side in a central network component such as a Home Subscriber Server (HSS). The tamper resistant device is usually represented as a Universal Integrated Circuit Card (UICC). However, this thesis aims at enabling devices without such a tamper resistant card to access IMS services. Regardless of whether the device disposes of the card or not, the long term security association

(18)

is used to create a short term server-specific security association that can be used to secure IMS service access. After successful completion of the bootstrapping procedure, the client and server are able to use the security association as a user-name and password in HTTP Digest authentication, or as a pre-shared secret in Pre-Shared Key Transport Layer Security (PSK-TLS).

The HSS can be seen as the central identity database of an IMS network. As such, it contains security values and user profiles. To enable the infrastructure introduced by this thesis, a subset of the user profile is shared with other IMS network components. This allows for centralized and simple administration and provisioning of user data, because the system distributes data automatically as necessary, while maintaining security. Part of this thesis is a Java implementation, which implements the concepts, procedures and mechanisms introduced by this work. In the following two sections, the motivation for this work, as well as its scope are described. The last section assists the reading and understanding of this thesis by giving a structural overview.

1.1 Motivation

The Fraunhofer Institute FOKUS, nationally and internationally known as a lead-ing research institute in the field of open communication systems, launched the ”Open IMS Playground”1in July 2004 as part of the German 3G Beyond National

Testbed2. The Fraunhofer FOKUS Open IMS Playground is a testbed that brings

together all major IMS core components (especially the FOKUS Open Source IMS Core (OSIMS) 3 4), created by Fraunhofer FOKUS and major industry players.

The playground is a unique, open and vendor-independent IMS test environment that can be used by academic and industrial institutions for early prototyping of new IMS related components, protocols and applications, as well as for testing and benchmarking of IMS components. Also, the interconnection to other IMS testbeds is currently under development in order to allow the experience of IMS concepts and IMS services to be shared with other partners.

The mission of the Next Generation Network Infrastructures (NGNI) department at FOKUS is to bring different NGN and IMS players together in one single place and build a 3GPP compliant IMS environment in order to offer professional services in the areas of technical studies, prototype development, infrastructure components, interoperability testing, and integration of new technologies.

1http://www.fokus.fraunhofer.de/ims/

2http://www.fokus.fraunhofer.de/national host/index.php?lang=en 3http://www.openimscore.org/

(19)

NGNI is therefore interested in this thesis, as it actively supports and extends the existing IMS playground and service demonstration facilities at FOKUS. This thesis also facilitates service access by implementing Single Sing-On (SSO) and provides advanced security mechanisms for IMS HTTP service access.

The implementation of this thesis has been integrated into the existing infrastruc-ture of the Open IMS Playground for the benefit of the entire research community. Furthermore, a large part of this thesis’s implementation is being used in a project with one of the main telecommunications industry players that will use the doc-umented binary prototype version of the Bootstrapping Server Function in the establishment of an NGN AAA test environment.

1.2 Scope

In this part, it is important to stress that this thesis focuses on 3rd generation (3G) networks. The security level of 3G authentication is considerably higher than the 2G SIM authentication and the FOKUS Open IMS Playground is a beyond-3G testbed. This thesis looks at IMS service level authentication from different angles. It takes into consideration relevant specifications spanning different standardiza-tion organizastandardiza-tions including, among others, 3GPP, 3GPP2, ETSI and OMA, while not loosing the focus on IMS services and service level authentication. Regarding specification conformance, this thesis aims at Release 6 specification conformance. Following the horizontally layered OSI model and the Next Generation Networks model, this thesis concentrates on the highest layer: the service layer. It will be investigated how authentication can be achieved in IMS networks, abstracting from lower protocol layers.

The work includes the design and implementation of a Bootstrapping Server Func-tion, a Network Application FuncFunc-tion, a HTTP to IMS gateway and a client appli-cation to demonstrate the bootstrapping procedure. Figure1.1 shows the scope of this thesis. The implementation includes the reference points Ua, Ub, Zh, and Zn. The HTTP to IMS gateway (not shown in figure 1.1, refer to 3.6) is an adaption of the 3GPP specified architecture in order to support HTTP clients that do not implement the Ua and Ub interface (such as Web browsers).

The infrastructure and its implementation have been designed to keep the neces-sary adaptations, that need to be made on the Application Server side, as small as possible. Service designers should not be limited in creating applications, as the GBA is intended to enrich the service layer capabilities and facilitate its use, rather than putting further limitations on it. The administrators of IMS applica-tions can enable the services for usage with the GBA with minimal effort.

(20)

Ub Ua Zh Zn HSS AS UE BSF NAF

Figure 1.1: The Generic Bootstrapping Architecture

relies on a special network configuration (especially DNS configuration). Certain Application servers should not be publicly reachable from the Internet. The Net-work Application Function has been designed to serve the client as the single point of entry and needs to be configured appropriately.

1.3 Structural Overview

This thesis has a clear structure. It contains six chapters that follow a straight-forward schema: state of the art → design → implementation → validation. The first chapter, ”Introduction”, introduces this work and outlines the motiva-tion to write it. Furthermore, the scope and structure of the work are covered by the first chapter.

The second chapter, ”Access to IMS Services”, describes the current state of the art and illustrates this work in the broad context of IMS and Next Generation Networks. It furthermore states what the IMS actually is and why it is useful. In addition, it lists the relevant specifications and gives a first overview of what the Generic Bootstrapping Architecture is.

The third chapter, ”Infrastructure Design and Requirements”, describes the in-frastructure introduced by this thesis and how it has been designed in detail. This includes the relevant components, reference points and different operation modes of the Generic Bootstrapping Architecture.

The fourth chapter, ”Software Implementation”, describes not only problems that were encountered during the design and implementation, but also general prob-lems that result from an insufficient specification, as well as how the probprob-lems are

(21)

solved by this implementation. It also describes the implementation features and implementation decisions. It is intended to provide a detailed description without simply providing a user manual. A Javadoc has been created to serve the code documentation purpose, while the written part of thesis aims at outlining prob-lems and solutions relevant to IMS application layer authentication.

The fifth chapter, ”Software Validation Within the FOKUS Open IMS Play-ground”, shows how the implementation has been validated within the FOKUS Open IMS Playground. This includes a short description of the services tested and how the validation scenarios work.

The final chapter, ”Summary and Outlook”, provides conclusion, recommenda-tions and other comments on the topic.

The appendix includes information that is too detailed to be included within the regular chapters such as code snippets, Diameter protocol message formats and normative procedures that are relevant and interesting for readers with a deep technical background.

At the end, the reference list (bibliography), as well as a list of abbreviations/-glossary can be found.

Each chapter contains a summary for the reader’s convenience.

Conventions used throughout this thesis are listed and explained in the follow-ing:

• All quotations extracted from referenced literature are given in quoted italic letters together with the source the of the quotation given in square brackets at the end of a quotation.

Example: ”This is an example quotation!” [the source as shown in the ref-erence list]

• All technical terms such as Attribute Value Pair (AVP) names, property file parameters, protocol headers, etc are written in a typescript font.

Example: UserNameAVP, parameter=value, Authorization

• All Java classes are written in italics. Also, filenames are written in italics. Example: de.fhg.fokus.class, bsf.properties

• All Uniform Resource Locators (URL) are written as hyperlinks in blue letters (only in the PDF version of this thesis). After clicking on them, the URL should be opened in your default browser.

Example: www.examplepage.org

• Generally, all references (sections, figures, etc) are shown as hyperlinks in blue letters (PDF version only). After clicking on the hyperlink, the PDF

(22)

document viewer should automatically jump to the referenced page in the document. Example: Section 1.3, Figure 1.1

• All Bibliography references are shown in square brackets and as hyperlinks (PDF version only). Again, by clicking on the reference, the PDF viewer should display the page with the referenced entry in the bibliography section. Example: [RFC2617]

(23)

Access to IMS Services

The International Telecommunication Union (ITU) defined the IMT-2000 (Inter-national Mobile Telecommunications-2000) for wireless communications networks of the 3rd generation (3G networks). 3G networks combine cellular access tech-nologies with the Internet in order to provide new services. The Internet Protocol Multimedia Subsystem (IMS) merges different access technologies with the very successful Internet paradigm in order to provide a new user experience where multimedia services are available at any time through ubiquitous network access. This chapter will clarify what the IMS actually is, why we need this, and which key components are used. At the end of this chapter, the most important speci-fications for this thesis are introduced and shortly discussed. Standardization is very important in todays fast changing telecommunication environments in order to assure interoperability across different vendors, as this is a key to success.

2.1 What Is the IMS and Why Is It Needed?

The IMS is a standardized network architecture for mobile operators for providing multimedia services. It is based, among others, on the standard Internet Protocol (IP) [RFC791] [RFC2460], the Session Initiation Protocol (SIP) [RFC3261] and the AAA protocol Diameter [RFC3588].

In order to fully understand the advantages drawn from the IMS, two very differ-ent paradigms have to be explained: circuit switching (CS) and packet switching (PS).

CS technology has been used since the beginning of telephony and is still used today for transporting voice and video in fixed and mobile networks. The CS do-main is do-mainly characterized by the dedicated communication path between two stations which is a connected sequence of links between network nodes. There is

(24)

a call-setup phase in which bandwidth is reserved for this connection on all nodes on the communication path. This can lead to inefficiency at times when the con-nection is not used at the maximum bandwidth by the connected parties, as the bandwidth has been reserved and cannot be used by other parties that share the same network. The advantage resulting from using CS technology is a guaranteed quality of service (QoS).

PS technology has been recognized to be a more efficient way of sharing network bandwidth. The Internet is based on PS technology. In PS, data is transmitted in short packets. Usually, there is an upper bound on the packet length. If the sender has longer messages to send, the data is split into a series of packets with the maximum length. Each packet contains signaling data which is used to route the messages to the right destination. There is no call-setup phase, messages are send right away, each of them containing the destination address. Based on the rate of signaling data to user data, PS can lead to more efficient bandwidth use, as each party can make use of the full bandwidth, if other users are not using the connection at a certain time. The drawback from PS is that the communication path is not reserved. It is therefore difficult to guarantee a certain QoS. Usually PS networks are best-effort networks, such as the Internet.

3G networks have a CS-domain and a PS-domain. Internet services can be pro-vided via the PS-domain, but QoS can hardly be assured. This is where the IMS comes into play. By employing the IMS QoS mechanisms, QoS can be assured although using PS technology. This is the first reason why IMS is needed but there are more. The following description gives an overview over the main reasons why the IMS is needed:

Quality of Service The IMS supports different QoS models [TS23.207] based on link-layer resource reservation protocols. It guarantees QoS by synchronizing session establishment and QoS provision.

Charging flexibility This allows for different business models. In CS, charging is usually based on the active connection time, while in PS, the number of transfered bytes is taken as the basis for charging the user. This twofold way of charging is not flexible enough for many Internet multimedia service scenarios. An operator might, for instance, offer a special rate for busi-ness video conferencing calls (which create a large amount of data as video streams tend to be large) over the PS domain based on the duration of the conference. One can think of many other business models an operator might want to employ apart from time-based charging such as flat rates or QoS-based charging models. The IMS provides greater flexibility in charging and supports different business models which is beneficial for operators (specific charging models) and users (fair prices).

(25)

Integration of different services As interfaces in IMS are standardized, service developers can create many different compatible services that run on IMS platforms. This provides operators with a large services portfolio that can be enriched by implementations of many different vendors. Of course, operators can also employ services yielded by own development. However, service diversity is also beneficial for end users, because every user can choose from a variety of services, only using and paying for those, that best fit its personal needs. Furthermore, the IMS can provide existing Internet services, that are already known to the users from browsing the web.

Service Single Sign-On By inserting the user identity into the requests (asserted user identity), centralized data management and Single Sign-on across many services becomes possible. This is highly beneficial for end users, because the necessity for providing credentials is minimized.

Apart from the reasons mentioned above, which are beneficial to operators as well as end-users, another reason for operators to run the IMS is obvious: Internet services like Skype threaten the business of the operators. The danger resulting from such services is that the operators’ business might be reduced to simply supplying the ”bit pipe”. Imagine, for example, flat rates for mobile telephony and Skype-enabled mobile phones. In this scenario, the operator provides con-nectivity and sells flat rates, but nothing else. The actual service is run by a third party and is outside the reach of the operator. The assumption today in the telecommunication sector is that in the near future the money will be made with (multimedia) services and content rather than plain telephony. This is why a central reason for the operators to deploy IMS today, is to generate revenue in the future by keeping control of the network and especially the services that will be run over their own networks. Therefore, IMS can be seen as the last chance for the operators to prevent the ”bit pipe” scenario and deploy a standardized and controllable infrastructure. If this last unified approach fails, if the IMS fails, the operators are likely to merely provide network access, while Internet service companies like Google, Yahoo, Skype, etc. are in control of the services.

2.2 Service Deployment Based on a Layered

Architecture

In NGNs (Next Generation Networks), service accessibility is leveraged by a lay-ered architecture which functionally separates network access, service control and

(26)

services. Well defined interfaces between the layers enable operators, R&D insti-tutes and vendors to profit from an industry spanning interoperability. In figure

2.1 the different layers are shown. They will be discussed in the following.

Services Session Control IMS Access Layer UMTS WLAN xDSL ...

Figure 2.1: The NGN Layered Architecture

Access Layer The access layer represents any network that transports IP traffic in a PS manner. A good example is the PS-domain of an UMTS network. Fixed access technologies such as ADSL are also part of this layer. The ac-cess layer is standardized by different organizations such as 3GPP, 3GPP2 (mobile access), and ETSI (fixed access). The different standardization or-ganizations will be introduced in the following sections. As the access layer is not the main focus of this thesis, this layer will not be discussed in detail. Specifications can be found on the organizations up-to-date web sites (please refer to the Bibliography section for the web sites’ addresses).

For this thesis, it will simply be assumed that we are able to use any device communicating with any network providing IP connectivity, which is as-sured by the standardized access layer technologies. It is important to note, that on the access layer level, the device/user is authenticated for the first time to the network using appropriated protocols depending on the access technology.

Session Control Layer In the IMS, the user is authenticated for the second time on the session control layer, although this is not mandatory for all session control systems. In 3GPP and 3GPP2, the Cx interface provides authentica-tion and authorizaauthentica-tion. In 3GPP, the Cx interface is specified in [TS29.228] and [TS29.229]. In 3GPP2, the Cx interface is specified analog to 3GPP in

(27)

[CxA] and [CxB]. In fixed line access, most terminals are missing a Univer-sal Integrated Circuit Card (UICC) which hosts the UniverUniver-sal Subscriber Identity Module (USIM) and/or IP Multimedia Services Identity Module (ISIM) applications, that are used for authentication purposes and access-ing the IMS. Therefore, for fixed line IMS access (terminals without UICC), the specification and standardization of more than one authentication mech-anism is probable but not yet done.

In addition to authentication and authorization, session handling is realized by the IMS core components on the service control layer. Please note that session handling is not necessarily required. The Internet for instance does not employ session handling. In the case of the IMS however, SIP traffic is controlled by the IMS core network elements on this layer of the overall NGN architecture. This enables full control of a session and features like charging and Quality of Service.

Service Layer This layer gathers different kind of services. This includes home operator IMS services, third-party IMS services, as well as Internet services. Authentication on this level is the main focus of this thesis and is still a field of research and specification efforts. By the end of this chapter, the reader should understand what the main problems in service layer authentication are, which solutions are currently in place, and how this thesis and its im-plementation contributes to this issue.

Note that authentication on every layer can be seen independently from the other layers. This does not have to be true for all services, an example might be the T-Online Number which is used on the access layer to grant access to the Internet but can be reused on the service layer to access services offered via the T-Online homepage such as email or a personal homepage.

This leads to the central question: where is user data stored, how is it dis-tributed, and which network elements should have access to this very sensible kind of data. The user is interested in keeping the amount of credentials needed for different sites as small as possible. The danger resulting from reusing the same credentials for different services or storing credentials in digital media, where they can be subject to theft and spying, are obvious. The well known answer to address this problem is SSO (Single Sign-On). SSO minimizes the necessity for an end user to provide credentials, without compromising security. There are different approaches to realize SSO and the transfer of identity information across the borders of a single domain.. For the IMS however, authentication on the service layer is addressed by dif-ferent specifications which will be discussed in the following sections. The next section describes the IMS core network elements and the Generic Boot-strapping Architecture which has been implemented as part of this thesis and which handles service layer authentication and authorization.

(28)

2.3 The IMS Architecture and Its Core Components

This section introduces the most important IMS components. As the IMS is a complex architecture with a number of different elements, only those parts relevant to the service layer authentication and authorization process will be discussed in detail. Please refer to figure 2.2 for an overview of the most important IMS components. HSS P-CSCF S-CSCF I-CSCF IMS Client on Mobile Phone Application Server

Media Server / Media Gateway / Signaling Gateway Access Network Access Network Legacy Networks (GSM, PSTN) P-CSCF Cx Mw Mw Mw Mw Mw Cx ISC Sh Mi Gm Fixed Line Workstation

Figure 2.2: The Simplified IMS Architecture

CSCF The CSCFs (Call Session Control Function) are SIP servers that handle SIP-based traffic in IMS networks. Being SIP agents, they are central com-ponents of every IMS as they process the SIP signaling. At FOKUS the CSCFs have been built on top of an existing SIP agent, the powerful SER (Sip Express Router)1 which has also initially been implemented at FOKUS. There are three different types of CSCFs: the P-CSCF (Proxy-CSCF), I-CSCF (Interrogating-I-CSCF) and S-I-CSCF (Serving-I-CSCF). All I-CSCFs are basically SIP proxies. There is a lot of shared functionality between them, this is why at FOKUS a common base system is used for all of them. Ev-ery entity is then configured differently based upon the special requirements dictated by its particular function (P-, I- or S-).

• P-CSCF: The Proxy-CSCF is the first point of contact (in the signaling plane) between the IMS terminal and the IMS network. From the SIP point of view, the P-CSCF is acting as an outbound/inbound SIP proxy

(29)

server. This means that all the requests initiated by the IMS terminal or destined for the IMS terminal traverse the P-CSCF. [camarillo] • I-CSCF: The Interrogating-CSCF is a SIP proxy located at the edge of

an administrative domain. The address of the I-CSCF is listed in the DNS (Domain Name System) records of the domain. [...] The I-CSCF retrieves user location information and routes the SIP request to the appropriate destination (typically an S-CSCF) [camarillo]

• S-CSCF: The Serving-CSCF is the central node of the signaling plane. The S-CSCF is essentially a SIP server, but it performs session controll as well. In addition to SIP server functionality the S-CSCF also acts as a SIP registrar. This means that it maintains a binding between the user location (e.g. the IP-address of the terminal the user is logged on) and the user’s SIP address of record (also known as the Public User Identity). [camarillo]

HSS The HSS in 3G IMS is an evolution of the Home Location Register (HLR) in GSM (Global System for Mobile Communications). It stores subscriber pro-file data (including Public and Private User Identity), service and charging profile data, filter criteria (for choosing an appropriate application server) and corresponding service trigger point information, and can be seen as the central AAA (Authentication, Authorization, Accounting) data base within the IMS architecture. The HSS also is a central component of the Generic Bootstrapping Architecture (GBA) as depicted by figure2.3. The GBA, be-ing the main focus of this thesis, will be explained in the followbe-ing sections. At this stage it is sufficient to know, that the HSS stores information such as a shared secret (between user and HSS) and other authentication and authorization information which can be used by the GBA components to grant (or deny) access to services within an IMS network.

Application Server The Application Servers (AS) host the SIP and HTTP ser-vices offered via the IMS infrastructure. This includes home network ap-plications offered by the IMS operator or third party apap-plications. Usually these applications are access restricted and secured by some kind of login procedure where access is granted to subscribed users only. The idea of the GBA is to relieve the ASs from security tasks on and reuse the authentica-tion and authorizaauthentica-tion informaauthentica-tion stored in the HSS for AS access decisions on the HTTP layer. In SIP communication the user identity is carried in a P-Asserted-Identity field. By using the GBA, the user identity can be inserted into requests toward the ASs in a X-3GPP-Asserted-Identity HTTP header.

(30)

Application servers can offer a predefined suite of services but can also offer a service creation environment where customized services can be deployed. Media Gateway / Media Server / Signaling Gateway This component is

usu-ally split into Breakout Gateway Control Function (BGCF), Media Resource Function Control (MRFC), Media Resource Function Processor (MRFP), Media Gateway Control Function (MGCF), Media Gateway (MGW) and Media Server. As all this is not relevant to the main focus of this thesis, all of the above media related components have been condensed into one component as depicted by figure 2.2. The function of all of the above is to deliver (e.g. announcements), mix (e.g. conference calls), and control me-dia streams and connect the IMS to the PSTN (Public Switched Telephone Network) and legacy networks. This includes low level functions like pro-tocol conversion between legacy propro-tocols (e.g. ISUP) and the IM domain call control protocols, choosing the correct CSCF depending on the routing number for incoming calls from legacy networks, establishing the bearer, translating codecs, and signaling to other networks.

The Reference Points The reference points (Cx, ISC, Sh, Gm, Mw, Mi) are interfaces supported by the corresponding network elements. The inter-faces are specified regarding requirements, exchanged messages, and proto-col specific settings by 3GPP. The Sh interface for example is a Diameter intra-operator interface that transports service and user related information, whereas the Cx Diameter interface is used to exchange location and authen-tication information and to authorize a user to access the IMS. The GBA relevant reference points will be discussed in more detail in the following sections.

This section should have provided you with a broad overview of what the core IMS elements are and why they are needed. The next section describes the HTTP protocol.

2.4 The Hypertext Transfer Protocol

As the Hypertext Transfer Protocol (HTTP) is a well-known protocol, it will be described here very briefly. Please refer to the referenced literature for more in-formation.

HTTP is a stateless request/response OSI Model layer 7 (application layer) pro-tocol for data transmission in networks between a server and a client. It is mainly

(31)

used to carry web site information and data in the World Wide Web. Web browsers support the HTTP protocol to display web sites in the browser. HTTP can there-fore be used to access IMS Application servers to retrieve service web sites. HTTP relies on a reliable transport protocol. In most cases TCP is used as the un-derlying transport layer protocol. HTTP is specified in [RFC1945] and [RFC2616]. It uses headers as information elements to provide the receiving party with relevant information such as employed user-agent, encoding information, content-length, content type, etc. The message content (for example a HTML Web site) is carried in the HTTP body.

HTTP defines a set of request methods (GET, POST, PUT, HEAD, etc.) that indicate the intended action to be performed at the receiving server. It further-more specifies numeric response status codes and textual response phrases, that indicate the result of the request.

Authentication for HTTP has been specified in [RFC2617]. HTTP supports Ba-sic and Digest Access Authentication. The BaBa-sic Authentication Scheme is not considered to be secure as user name and password are transmitted in cleartext (if no transport security is used). The Digest Scheme is based on cryptographic hashes and can be used in the Generic Bootstrapping Architecture between the client and a Network Application function.

The next section introduces the Generic Bootstrapping Architecture and should give you - based on the understanding of the layered architecture and the IMS elements - a feeling of why the GBA is a useful enhancement of the IMS architec-ture.

2.5 The Generic Bootstrapping Architecture

The GBA is part of the GAA (Generic Authentication Architecture) which en-sures a secure and encrypted access to IMS services on the service layer (see 2.1). The GAA relies on certificates, authentication proxies and shared secrets.

The GBA implementation of this thesis covers authentication by means of shared secrets and implements an authentication proxy in order to serve all applications that share a need for authentication and authorization of a client (the user equip-ment) before further communication can take place with the connected Applica-tion Server. Figure2.3shows the GBA architecture and how it fits into the overall IMS architecture. The GBA consists mainly of two new elements: the Bootstrap-ping Server Function (BSF) and the Network Application Function (NAF). UE in figure 2.3 stands for User Equipment, HSS and AS have already been intro-duced in the previous section. Before going into detail how the GBA works and

(32)

Ub Ua Zh Zn HSS AS UE BSF NAF

Figure 2.3: The Generic Bootstrapping Architecture

which reference points have been defined, I want to raise a few more words on the layered architecture of NGNs and how the GBA fits into this approach. As previously described, the vertical structure of NGNs consists of three layers. The access layer, the session control layer and the service layer. The concept of GBA - simplifying service access - with its elements BSF and NAF is located in the service layer. Please have a look at figure 2.4.

Figure 2.4 reuses and merges figure 2.2 and figure 2.3 to demonstrate the

lay-Ub Ua Zh Zn BSF NAF HSS P-CSCF S-CSCF I-CSCF UE Application Server

Media Server / Media Gateway / Signaling Gateway Access Network Legacy Networks (GSM, PSTN) P-CSCF Cx Mw Mw Mw Mw Mw Cx ISC Sh Mi Gm Service Access Session Control Access Networks

Figure 2.4: The GBA and IMS Architecture Interpreted as NGN Layers

ered NGN architecture. It is important to note, that this figure demonstrates the concept, rather than trying to allocate network elements to concrete layers. This

(33)

means that the overall IMS architecture with CSCFs et cetera - being a session control system - is located in the session control layer. Following this logic con-sequently, the GBA - being a service access supporting system - is located in the service layer. In order to avoid network components to be depicted twice (like HSS, AS, and UE) the connectors span multiple layers. This implies that the GBA part of figure 2.4 (service layer) can itself be split into different layers, but taken as a general concept, it should be placed in the service layer.

In the following, the GBA entities will be described as depicted by figure 2.3. Especially the two introduced elements BSF and NAF need to be explained as well as the interworking of these components with the existing elements such as HSS and AS:

BSF The Bootstrapping Server Function (BSF) has three interfaces: Ub, Zn and Zh. It is publicly reachable from the Internet on the Ub interface, whereas the interfaces Zn and Zh are only accessible from within the operators net-work. The BSF can also be configured to accept requests from outside of the operators network on the Zn interface, but at this stage the BSF shall be assumed to communicate with NAFs from within the operators network only.

On the Ub interface the BSF acts as a Hypertext Transfer Protocol (HTTP) server. The BSF can optionally be configured to support HTTPS (Trans-port Layer Security (TLS) over HTTP) on the Ub interface.

The interfaces Zh and Zn are Diameter interfaces. On the Zh interface the BSF communicates with the HSS, whereas on the Zn interface it is listen-ing for Diameter requests from the NAF. The BSF therefore also acts as a Diameter server.

NAF The Network Application Function (NAF) has two interfaces: Ua and Zn. On the Ua interface it listens for HTTP/HTTPS requests and therefore acts as a HTTP/S server. On the Zn interface it communicates with the BSF exchanging Diameter messages. The connection with the AS is also a HTTP connection. Optionally this connection can be secured. This also depends on the location of the AS. At this stage it shall be assumed that the AS is located within the operators network and is not publicly reachable from the Internet. Therefore no further security measures are necessary on this interface. If the connection has to established via untrusted networks, confidentiality and integrity protection can be provided using NDS/IP mechanisms as specified in [TS33.210]. Because the AP terminates the TLS tunnel from UE, it is also possible to establish a TLS tunnel with ASs.

(34)

with the GBA infrastructure. It has already been authenticated on the ac-cess layer (depending on the technology used to establish a connection) at the time of the first request to the GBA infrastructure components. It might also have been authenticated on the session control layer (IMS authentica-tion). The UE can then proceed to authenticate with the GBA in order to access the services offered by the AS. How this occurs will be discussed in the following.

In the setup for this thesis it will be assumed that the HSS and the ASs reside within the operators network and cannot be reached from the Internet. The BSF and NAF have public HTTP/S interfaces in order to communicate with the UE. There are also ASs that have public interface but they must then apply their own security measures on these interfaces.

It will now be described in detail how the GBA works and which messages are exchanged. Note that the following chapters also provide detailed information on the bootstrapping procedure. The following first description is given to introduce the general (simplified) concept, which will be further detailed and modified ac-cording to the different standardization organizations.

Figure 2.5 shows a sequence chart of the very general bootstrapping procedure.

UE BSF HSS NAF 1. GET 2. Redirect 3. GET 6. 401, Nonce 7. GET, RES 4. Get Vectors 5. Vectors 9. 200 OK 10. GET 11. Get GUSS 8. if RES = XRES 12. GUSS 13. 200 OK

(35)

1. GET: this is a HTTP GET transfered over interface Ua. In this first step the user requests a web page residing on an AS, which is hidden behind the NAF. The NAF acts as a reverse proxy. This means that requests targeting an AS will be directed to the NAF due to DNS and network configuration. An example: The user enters http://service.open-ims. org/servicein his web browser in order to access his favorite service. Due to DNS configuration service.open-ims.org will be resolved to the IP address of the NAF. The browser is therefore sending the request to the NAF. This is why the sequence chart shows no application servers. Until the user has actually been authenticated, there is no contact with any AS. 2. Redirect: Upon receiving the request from step 1, the NAF checks if the user

has already been authenticated. This is done by checking for cookies (that should previously have been set by the NAF if the user has already been authenticated) and checking for special HTTP headers, that would have been set by a GBA-capable client in order to demonstrate that successful authentication has already taken place. If authentication has not taken place yet, the NAF redirects the client to the BSF, where the bootstrapping procedure begins.

3. GET: The client accesses the BSF following the redirect by the NAF. This is interface Ub communication. Note that this step actually consists of of two other steps. The user first accesses the BSF which denies further communication, if there is no HTTP header carrying some user identifier. The client then accesses the BSF providing a user identifier.

4. Get Vectors: In this step the BSF requests Authentication Vectors (AV) from the HSS over reference point Zh for the user identifier that has been obtained from the client in the previous step. This is Diameter communication. The Diameter protocol itself and the exchanged messages will be discussed in a later section. The Authentication Vectors consist of a nonce (number used once) value, a respected response value XRES and further security values. Additionally, Generic User Security Settings (GUSS) are transfered from the HSS to the BSF. The GUSS carry user identities that are recognized at the AS, and authorization values, which can be transfered to the NAF. The NAF can decide - based on the GUSS data - if a user is authorized to use a certain type of service.

However, at this stage the BSF requests the Authentication Vectors which are needed to challenge the client and proceed with the authentication. 5. Vectors: The HSS returns the Authentication Vectors for that user. This

(36)

client response digest against a digest of the XRES value in step 8.

A digest is a digital fingerprint of any kind of data. Another term for digest is hash value. Hash values are generated by hash functions which provide a method of turning some kind of data into a hexadecimal notation which can then be handled by computers. A good hash function does not provide the same number for different input data with a very high probability. The digital fingerprint can then be called unique and servers as an unique iden-tifier.

The authentication vectors furthermore contain parts of the key material that is used to secure the communication between the client and the NAF. 6. 401, Nonce: The BSF determines that the client has not yet been

authen-ticated and challenges the client with the nonce value. From this value the client need to be able to generate the response RES by applying the IMS Authentication and Key Agreement (AKA) schema [TS33.102], [TS35.205]. The client can also authenticate the server as AKA provides mutual authen-tication.

7. GET RES: The client calculates the value RES with the given nonce from the BSF. The RES is only identical to the expected XRES if the client is in possession of the nonce and the secret shared between the client and the HSS (the secret need to be agreed during IMS contract establishment). For a detailed description of the algorithm by which the RES is calculated please refer to [TS33.102] and [TS35.205]. A digest of the calculated value RES is send to the BSF.

The client furthermore calculates the key material Ks NAF used for reference point Ua security mechanisms.

8. if RES = XRES: The BSF verifies that the client calculated digest of the value RES matches the digest of the expected response XRES and that the client must therefore be in possession of the correct secret key. Note that by using this security mechanism, the secret (which is only known by HSS and UE and which is even unknown to the BSF) is never actually transfered over the potentially insecure communication path.

If the values are identical, the client is allowed further communication with BSF and NAF. In case of failure, a HTTP 401 Unauthorized (carrying the nonce in a special HTTP header) is send to the client.

9. 200 OK: This HTTP 200 OK message indicates the successful authentication. The client is now being redirected to the NAF. Note that this thesis covers different approaches of how successful authentication is demonstrated to the NAF. This can be done by setting special HTTP headers (this requires a

(37)

special IMS GBA client as standard browsers do not support this) or setting cookies on the client machine. The cookie approach has the advantage that it works with standard browsers and no client side adaptations are necessary. This thesis will introduce a mechanism to carry out the GBA procedures with a standard browser in section 3.4.

10. GET: The client follows the redirection back to the NAF. It now needs to demonstrate to the NAF that is has successfully authenticated with the BSF. This can be done by applying the HTTP Digest mechanism [RFC2617] or the NAF can check for cookies. More details on this in the following chapters. 11. Get GUSS: The NAF obtains the key material and GUSS from the BSF over

reference point Zn. This is Diameter communication.

12. GUSS: The BSF returns the GUSS and key material used to secure reference point Ua.

13. 200 OK: The client is allowed to access the AS through the NAF. The NAF acts as a reverse proxy and all requests between client and AS go through the NAF. This enables service developers to forget about authentication and channel security. The NAF (with support from the BSF) handles au-thentication, authorization, and channel security and relives the connected applications from these tasks by acting as a reverse proxy providing SSO. The authentication and reverse proxy behavior of the NAF will also be dis-cussed in more depth in section 3.5.

This section should have given you a rough idea of what the Generic Bootstrapping Architecture is and why it is needed. The next section will introduce the stan-dardization organizations that are important for this thesis and briefly discuss the specifications that provide the basis for the implementation.

2.6 The Standardization Organizations and

Specification Impact

This section shortly describes the standardization organizations that have spec-ified large parts of this thesis implementation. Each subsection will introduce an organization, shortly describe its structure and give an overview of the most important specifications.

(38)

2.6.1 Third Generation Partnership Project

The Third Generation Partnership Project (3GPP)2was established in December

1998 by the signing of ”The 3rd Generation Partnership Project Agreement”. It is a collaboration agreement that unifies telecommunications standards bodies known as ”Organizational Partners”. These Organizational Partners currently include:

• Association of Radio Industries and Businesses (ARIB) 3

• European Telecommunications Standards Institute (ETSI) 4

• China Communications Standards Association (CCSA) 5

• Alliance for Telecommunications Industry Solutions (ATIS, T1) 6

• Telecommunications Technology Association (TTA) 7

• Telecommunication Technology Committee (TTC) 8

In addition to the Organizational Partners there are Market Representation Part-ners, which provide the partnership with a ”consolidated view of market require-ments” [www3GPP]. These partners include the GSM Association 9, the UMTS

Forum 10, 3G Americas 11, the IPv6 Forum12, and more. Note that this is not an

exhaustive list.

3GPP was established to publish technical specifications. Its original scope was: ”to produce globally applicable Technical Specifications and Technical Reports for a 3rd Generation Mobile System based on evolved GSM core networks and the radio access technologies that they support (i.e. Universal Terrestrial Radio Ac-cess (UTRA) both Frequency Division Duplex (FDD) and Time Division Duplex (TDD) modes). The scope was subsequently amended to include the maintenance

2http://www.3gpp.org/ 3http://www.arib.or.jp/english/html/arib/index.html 4http://www.etsi.org/ 5http://www.ccsa.org.cn/english/intro.php 6http://www.atis.org/ 7http://www.tta.or.kr/English/new/main/index.htm 8http://www.ttc.or.jp/e/index.html 9http://www.gsmworld.com/index.shtml 10http://www.umts-forum.org/servlet/dycon/ztumts/umts/Live/en/umts/Home 11http://www.3gamericas.org/English/index.cfm 12http://www.ipv6forum.org/

(39)

and development of the Global System for Mobile communication (GSM) Techni-cal Specifications and TechniTechni-cal Reports including evolved radio access technologies (e.g. General Packet Radio Service (GPRS) and Enhanced Data rates for GSM Evolution (EDGE)).” [www3GPP]

The following list introduces the main 3GPP specifications that are relevant to this thesis.

3GPP TS 33.919 [TS33.919], Generic Authentication Architecture (GAA); Sys-tem description.

Many services require mutual authentication between the UE and the appli-cation server. ”Since a lot of appliappli-cations share this common need for a peer authentication mechanism, it has been considered useful to specify a Generic Authentication Architecture (GAA). This GAA describes a generic archi-tecture for peer authentication that can a priori serve for any (present and future) application.” [TS33.919] This document describes the framework for the GAA and how the different building blocks are combined to provide a secure infrastructure.

3GPP TS 33.220 [TS33.220], Generic bootstrapping architecture.

This specification is the general description of the GBA and defines require-ments of all involved components such as BSF, NAF, reference points and transmitted values.

3GPP TS 24.109 [TS24.109], Bootstrapping interface (Ub) and network appli-cation function interface (Ua); Protocol details.

This document defines the Ub interface and the bootstrapped security as-sociation usage over the Ua interface. ”The purpose of the Ub interface is to create a security association between UE and BSF for further usage in GAA applications. The purpose of the Ua interface is to use the so created bootstrapped security association between UE and NAF for secure communi-cation.” [TS24.109]

3GPP TS 33.222 [TS33.222], Access to network application functions using Hy-pertext Transfer Protocol over Transport Layer Security (HTTPS).

This specification defines stage 3 for the Authentication Proxy usage which provides secure access to the NAF using HTTP over TLS.

3GPP TS 29.109 [TS29.109], Zh and Zn Interfaces based on the Diameter pro-tocol.

(40)

Diameter interfaces. Note that this specification is partly based on re-usage of Cx interface messages such as Auth-Request and Multimedia-Auth-Answer that have originally been defined for usage between CSCF and HSS.

S3-060608-TS33.223-GBA-Push-v0.1.0 [TS33.223], Generic Bootstrapping Ar-chitecture (GBA) Push Function.

This document is still in a very draft status. It was published in August 2006 and many details are still missing. This is why it currently has no impact on the implementation. It is a functional add-on for the GAA. The GBA Push Function is a mechanism to bootstrap a security association between the NAF and the UE, without forcing the UE to contact the BSF to initiate the bootstrapping procedure. ”The adoption of GAA by other stan-dardization bodies showed that some services can not make the assumption that the User Equipment (UE) has always the possibility to connect to the Bootstrapping Server Function (BSF). Hence, this specification introduces and specifies a GBA Push Function. [TS33.223].

As GBA-push is not considered by the implementation, it will not be ex-plained in detail. The specification is given here simply to allow a broad overview of the specification spectrum. Please refer to [TS33.223] for more details on the GBA Push Function.

3GPP TS 33.221 [TS33.221], Support for subscriber certificates.

This document specifies subscriber certificate distribution and signaling pro-cedures for support of issuing certificates to subscribers. The Implementa-tion currently offers subscriber certificate enrollment for Mozilla Firefox and Internet Explorer browsers only.

3GPP TS 33.920 [TS33.920], SIM card based Generic Bootstrapping Architec-ture (GBA) Early implementation feaArchitec-ture.

”3GPP defined the Generic Bootstrapping Architecture (GBA) in Release 6. The Release 6 GBA is based on 3G USIMs and ISIMs, i.e., 3G GBA [TS33.220]. The security level of 3G Authentication and Key Agreement is higher than the 2G SIM authentication. On the other hand, there are more than one billion people with SIMs in their phones and it will take long time to provision UICCs capable of 3G authentication to such a large population. Meanwhile there should be a way to offer services whose authentication is based on GAA also to 2G subscribers. [...] It should be noted that the work outlined in this feature does not require any change to the existing SIM spec-ifications, in particular GBA U as in 3G GBA will not be included in 2G GBA.” [TS33.920]

(41)

Again, this document is listed here to give a complete overview of the spec-ification landscape related to GAA and GBA.

2.6.2 Third Generation Partnership Project 2

While 3GPP was established to evolve GSM specifications, the Third Genera-tion Partnership Project 2 (3GPP2) 13 was established to evolve North American

and Asian cellular networks based on ANSI/TIA/EIA-41 standards and especially CDMA2000 radio access into a 3G system. 3GPP2 is very similar to 3GPP in its structure and scope. Like 3GPP it is a partnership project of organizational partners. ”Although discussions did take place between ETSI and the ANSI-41 community with a view to consolidating collaboration efforts for all ITU ”family members,” in the end it was deemed appropriate that a parallel Partnership Project be established - ”3GPP2,” which, like its sister project 3GPP, embodies the ben-efits of a collaborative effort (timely delivery of output, speedy working methods), while at the same time benefiting from recognition as a specifications-developing body, providing easier access of the outputs into the ITU after transposition of the specifications in a Standards Development Organization (SDO) into a standard and submittal via the national process, as applicable, into the ITU.” [www3GPP2] Most of the organizational partners of 3GPP2 are also organizational partners of 3GPP. The organizational partners are are:

• Association of Radio Industries and Businesses (ARIB) • China Communications Standards Association (CCSA) • Telecommunications Industry Association (TIA) 14

• Telecommunications Technology Association (TTA) • Telecommunication Technology Committee (TTC)

The Market Representation Partners are: the CDMA Development Group15, the

IPv6 Forum, the International 450 Association (IA 450) 16, and MobileIGNITE 17. 13http://www.3gpp2.org/ 14http://www.tiaonline.org/ 15http://www.cdg.org/ 16http://www.450world.org/ 17http://www.mobileignite.org/

(42)

The following list introduces the main 3GPP2 specifications that are relevant to this thesis.

S.S0109-0 v1.0 [S.S0109], Generic Bootstrapping Architecture (GBA) Frame-work.

This document describes the GBA, its security features, and the general mechanism to bootstrap key material for application security. This includes an architecture overview, architecture requirements, and the detailed pro-cedure how to bootstrap credentials similar to [TS33.220]. Note that the implementation of this thesis will concentrate on conformance to the 3GPP specifications keeping in mind 3GPP2.

S.S0114-0 v1.0 [S.S0114], Security Mechanisms using GBA.

This specification defines a security mechanism for using the keys, that have been generated using the GBA, to secure interface Ua. The document cur-rently specifies only one mechanism which is TLS with Pre-Shared Keys. This is very restrictive. The specification is just given for completeness, but will not be realized by the implementation.

2.6.3 ETSI / TISPAN

The European Telecommunications Standards Institute (ETSI) 18 is a standard-ization organstandard-ization of the telecommunications industry in Europe. It was created in 1988 and is an independent and non-profit organization with worldwide pro-jection. Its mission is to produce telecommunications standards for today and for the future. ETSI has done so by, for example, standardizing the GSM cell phone system.

ETSI has 699 members from 55 countries inside and outside Europe. This in-cludes, among others, manufacturers, service providers, network operators, and research bodies. Note that 3GPP and TISPAN are ETSI standardization bodies. While 3GPP is dedicated to UMTS specification efforts, Telecoms & Internet con-verged Services & Protocols for Advanced Networks (TISPAN)19is specializing in

fixed networks and Internet convergence. TISPAN was created in 2003 from the fusion of TIPHON (Internet Protocol Harmonization Over Networks) and SPAN (Services and Protocols for Advanced Networks).

”Building upon the work already done by 3GPP in creating the SIP-based IMS (IP Multimedia Subsystem), TISPAN and 3GPP are now working together to define

18http://www.etsi.org/ 19http://www.etsi.org/tispan/

(43)

a harmonized IMS-centric core for both wireless and wireline networks. This har-monized ALL IP network has the potential to provide a completely new telecom business model for both fixed and mobile network operators. Access independent IMS will be a key enabler for fixed/mobile convergence, reducing network instal-lation and maintenance costs, and allowing new services to be rapidly developed and deployed to satisfy new market demands. NGN Release 1 was launched by TISPAN in December 2005, providing the robust and open standards that industry can use as a reliable basis for the development and implementation of the first generation of NGN systems. TISPAN is now working on Release 2, with a focus on enhanced mobility, new services and content delivery with improved security and network management.” [wwwTISPAN]

The following list shows the relevant specifications:

ETSI TS 187 003 [ETSI187003], NGN Security; Security Architecture.

This document defines a stage 2, NGN release 1 security architecture. It does not define application/service layer access but explicitly names the 3GPP GAA and GBA Bootstrapping for application layer security.

Figure2.6 gives a high level overview over the TISPAN security architecture which includes authentication on all layers. This thesis focuses on the service

ISIM AKA mode

NASS Authentication (e.g. IEEE 802.1x/PANA NASS credentials ISIM GBA -U mode V - UAAF AMF H - UAAF PDBF S-CSCF UPSF NAF/AS BSF P-CSCF IMS AKA Security

association setup Ut Secure session

(GBA Bootstrapping, opt)

Diameter

Figure 2.6: The TISPAN NGN Security Architecture [ETSI187003]

layer. As - on the service layer - the TISPAN architecture relies on 3GPP GAA/GBA, the 3GPP specifications, that have already been introduced in subsection 2.6.1, are also relevant within the TISPAN/NGN context. ETSI TS 183 033 [ETSI183033], Diameter based protocol for the interfaces

(44)

Func-tion/Subscription Locator Function; Signaling flows and protocol details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, modified].

This specification is the ETSI TISPAN endorsement of [TS29.228] and also [TS29.229] and provides adaptations in order to comply with the require-ments of NGN Release 1. The most important parts of this document are the protocol extensions (Cx interface) for the support of HTTP Digest au-thentication. This includes the definition of new AVPs.

2.6.4 Cable Television Laboratories

The Cable Television Laboratories, Inc. (CableLabs )R 20 is a non-profit research

and development consortium that was founded in 1988 and contains more than 45 members. The members are cable television system operators. CableLabs’s objective is to support its members in integrating technical advancements in cable telecommunications technologies into their business objectives and enable inter-operability among various cable systems.

”CableLabs received copyright licenses from the ETSI to reproduce, modify, and distribute the 3GPP specifications contained in the PacketCable IMS Delta Specifi-cations. CableLabs will submit these enhancements to the 3GPP for incorporation into the IMS specifications. As this occurs, PacketCable IMS Delta Specifica-tions will be withdrawn and replaced with direct references to 3GPP IMS specifi-cations.”[wwwCable]

The following list includes specifications that are based upon 3GPP specifications and have been modified by CableLabs for the benefit of the cable industry. The 3GPP specification modified by CableLabs are commonly referred to as Packet-Cable Delta specifications.

PKT-SP-33.220-I01-060406 [Cable33.220], PacketCable IMS Delta Specifica-tions Generic Authentication Architecture (GAA); Generic bootstrapping architecture Specification 3GPP TS 33.220.

This document introduces new HTTP Digest Over TLS enhancements to the Generic Bootstrapping Architecture. This is referred to as GBA H. The bootstrapping procedure starts by establishing a TLS tunnel between the UE and the BSF. This is server side authenticated TLS. The UE authenti-cates the BSF by the certificate presented by the BSF. After establishing the TLS tunnel, the HTTP Digest mechanism is used to derive the key material between the UE and the BSF.

This additional specification allows the UE to bootstrap the session keys

(45)

based on 3GPP AKA or by using the HTTP Digest over TLS mechanism. Note that the HSS needs to support this as the authentication vector con-tents need to be calculated based on the used authentication method and algorithm to allow the BSF to calculate a challenge.

The Fraunhofer Home Subscriber Server (FHoSS) used in the Open IMS Playground is currently being adapted to support HTTP Digest authenti-cation.

PKT-SP-29.109-I01-060914 [Cable29.109], PacketCable 2.0 IMS Delta Specifi-cations Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on the Diameter protocol; Stage 3 Specification 3GPP TS 29.109. This specification is basically the same as [TS29.109] but defines the new au-thentication scheme ”SIP-Digest” according to [Cable29.229] and [Cable29.228].

2.6.5 Open Mobile Alliance

The Open Mobile Alliance (OMA) is an industry forum gathering leading mobile operators, device and network suppliers, information technology companies, and content and service providers. The OMA aims at developing market driven, in-teroperable mobile service enablers. The term ”service enabler” generally stands for a technology to be used in the development, deployment or operation of a service, so as to ”enable” the service. It is usually defined in a specification, or a set of specifications. The OMA publishes such service enabler specifications, as for examples: presence enhanced communication, location services, and group management.

OMA was formed in June 2002 and has so far integrated the following organi-zations: Location Interoperability Forum (LIF), WAP Forum, Mobile Gaming Interoperability Forum (MGIF), SyncML Initiative, Wireless Village, MMS-IOP (Multimedia Messaging Interoperability Process), and the Mobile Wireless In-ternet Forum (MWIF). ”This consolidation promotes end-to-end interoperability across different devices, geographies, service providers, operators, and networks, and further supports OMA’s market and user requirements focus to guide the spec-ification work.” [wwwOMA]

There are four categories of OMA member companies: sponsor, full, associate and supporter members. The member companies include mobile operators, informa-tion technology companies, wireless vendors, and content provider. The impressive up to date list of current members including IBM, Microsoft, Nokia, and many more, can be obtained from the official OMA website 21.

References

Related documents

The novel “A Gathering of Old Men” is a superior narrative of the highest order in establishing the manhood of the Black Louisiana community.. Gaines allegorizes the

What is the evidence regarding the impacts of specific prevention program models in reducing child physical abuse and neglect.. Methodology Examination

Completely free flowing traffic would increase the dangers faced by traffic wishing to access the A24 from the many side roads as there would no longer be pauses in the A24

Getters can be member functions taking no parameter and returning a T (for example get_z above), or a free function taking a pointer to the exposed class and returning a T,

VENDOR NAME DESCRIPTION AMOUNT DELL MARKETING LP COMPUTER SUPPLIES 9,195.90 OREGON DEPT OF ENVIRONMENTAL Q PROFESSIONAL SERVICES 3,200.00 KAN DI KI LLC MEDICAL SERVICES

The electoral formula does not allow a dominance of the largest constituent people, as a majority of nominally Bosniak members of the state presidency only occurs if one of the

The different phases of the eLearning process: training needs analysis, search and discovery of learning content, courseware organisation, courseware delivery and