Fraunhofer FOKUSTechnische Universitat Berlin Institut fur Offene

Kommunikationssysteme

Design and Implementation of a HTTP-BasedAuthentication Infrastructure for Service Access to

the IP Multimedia Subsystem

Diplomarbeit

Sebastian Wahle

Berlin, 25. Januar 2007

Fakultat IV - Elektrotechnik und InformatikLehrstuhl Architekturen der Vermittlungsknoten (AV)Franklinstr. 28-29, D-10587 BerlinSupervisor: Prof. Dr. Ing. habil Thomas MagedanzAssistant supervisor: Dipl. Wi-Ing. Peter WeikMatrikelnummer: 203593

Fraunhofer FOKUSTechnische Universitat Berlin Institut fur Offene

Kommunikationssysteme

Design and Implementation of a HTTP-BasedAuthentication Infrastructure for Service Access to

the IP Multimedia Subsystem

Diplomarbeit

Sebastian Wahle

Berlin, 25. Januar 2007

Eidesstattliche Erklarung

Hiermit versichere ich, Sebastian Wahle, an Eidesstatt, die vorliegende Arbeitohne unerlaubte Hilfsmittel, selbststandig, eigenhandig und unter ausschließlicherVerwendung der angegebenen Literatur erstellt zu haben.

Berlin, 24. Januar 2007

Sebastian Wahle

Ich danke meinen Eltern, Claudia und Wolf-Dietrich Wahle fur IhreSelbstlosigkeit und jahrelangen Entbehrungen.

Ich danke Maria Hommeyer, meiner zukunftigen Frau, fur ihre Liebe.

Ich danke weiterhin Prof. Dr. Ing. habil Thomas Magedanz und Dipl. Wi-Ing.Peter Weik fur die Moglichkeit, diese Arbeit zu schreiben und die gute

Betreuung, die ich wahrend des letzten Jahres erfahren habe.

Abstract

This thesis describes how HTTP access to IP Multimedia Subsystem (IMS) ser-vices can be secured (authentication, authorization and channel security) reusinguser identity information and security values existing in the central IMS networkdatabase, the Home Subscriber Server (HSS). The 3rd Generation PartnershipProject (3GPP) proposed and specified the Generic Bootstrapping Architecture(GBA), which is used to bootstrap a security association between a client anda server and which has been the fundamental design pattern for the infrastruc-ture layout. The GBA consist mainly of two server components: a BootstrappingServer 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 isbeneficial for operators and end users. A broad overview of the specification andstandardization landscape is given as well as the interconnection between existingstandards that are relevant for the GBA.This written thesis is accompanied by a software implementation of more than15000 lines of code that have been written in Java. The authentication servercomponents like BSF and NAF as well as extensions such as a HTTP to IMSgateway (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 thespecifications, reusing some standardized elements, in order to support not onlyGBA-capable IMS clients, but also standard web browsers. This is useful asGBA-capable IMS clients are currently not publicly available (in contrast to webbrowsers).

vii

Abstract

viii

Contents

Abstract vii

List of Figures xiii

List of Tables xv

1 Introduction 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Structural Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Access to IMS Services 72.1 What Is the IMS and Why Is It Needed? . . . . . . . . . . . . . . 72.2 Service Deployment Based on a Layered Architecture . . . . . . . 92.3 The IMS Architecture and Its Core Components . . . . . . . . . . 122.4 The Hypertext Transfer Protocol . . . . . . . . . . . . . . . . . . 142.5 The Generic Bootstrapping Architecture . . . . . . . . . . . . . . 152.6 The Standardization Organizations and Specification Impact . . . 21

2.6.1 Third Generation Partnership Project . . . . . . . . . . . . 222.6.2 Third Generation Partnership Project 2 . . . . . . . . . . 252.6.3 ETSI / TISPAN . . . . . . . . . . . . . . . . . . . . . . . 262.6.4 Cable Television Laboratories . . . . . . . . . . . . . . . . 282.6.5 Open Mobile Alliance . . . . . . . . . . . . . . . . . . . . . 292.6.6 Advances to IP Multimedia Subsystem (A-IMS) . . . . . . 31

2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Infrastructure Design and Requirements 353.1 2G GBA, GBA ME and GBA U . . . . . . . . . . . . . . . . . . . 353.2 The Diameter Protocol . . . . . . . . . . . . . . . . . . . . . . . . 363.3 Standard GBA With Mobile Equipment . . . . . . . . . . . . . . 38

3.3.1 The Bootstrapping Procedure . . . . . . . . . . . . . . . . 393.3.2 Usage of the Bootstrapped Security Association on UE-NAF

Communication . . . . . . . . . . . . . . . . . . . . . . . . 443.4 Fixed Line GBA Access Without UICC/ISIM . . . . . . . . . . . 48

ix

Contents

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 614.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 CookieProblem . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 955.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

5.6 The XML Document Management Service . . . . . . . . . . . . . 104

x

Contents

6 Summary and Outlook 107

A German Summary 109

B Diameter Commands 111B.1 Multimedia-Auth-Request (MAR) . . . . . . . . . . . . . . . . . . 111B.2 Multimedia-Auth-Answer (MAA) . . . . . . . . . . . . . . . . . . 112B.3 Bootstrapping-Info-Request (BIR) . . . . . . . . . . . . . . . . . . 112B.4 Bootstrapping-Info-Answer (BIA) . . . . . . . . . . . . . . . . . . 113

C Specification of the Key Derivation Procedure 115C.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115C.2 Generic Key Derivation Function . . . . . . . . . . . . . . . . . . 115

C.2.1 Input Parameter Encoding . . . . . . . . . . . . . . . . . . 116C.3 NAF Specific Key Derivation in GBA and GBA U . . . . . . . . . 117

D GBA-UserSecSettings XML definition 119

E Sample Configuration Files 123E.1 The BSF Configuration File . . . . . . . . . . . . . . . . . . . . . 123E.2 The NAF Configuration File . . . . . . . . . . . . . . . . . . . . . 124E.3 The GBA Demonstration Client Configuration File . . . . . . . . 126E.4 The Diameter Peer Configuration File . . . . . . . . . . . . . . . . 128E.5 The HTTP2IMS GW User Provisioning File . . . . . . . . . . . . 129

F Related Work and Patents 131

Bibliography xvii

Abbreviations and Glossary xxiii

xi

Contents

xii

List of Figures

1.1 The Generic Bootstrapping Architecture . . . . . . . . . . . . . . 4

2.1 The NGN Layered Architecture . . . . . . . . . . . . . . . . . . . 102.2 The Simplified IMS Architecture . . . . . . . . . . . . . . . . . . . 122.3 The Generic Bootstrapping Architecture . . . . . . . . . . . . . . 162.4 The GBA and IMS Architecture Interpreted as NGN Layers . . . 162.5 The General Bootstrapping procedure . . . . . . . . . . . . . . . . 182.6 The TISPAN NGN Security Architecture [ETSI187003] . . . . . . 272.7 The A-IMS Architecture Overview [AIMS] . . . . . . . . . . . . . 33

3.1 The Diameter Message Format [RFC3588] . . . . . . . . . . . . . 373.2 The Bootstrapping Procedure . . . . . . . . . . . . . . . . . . . . 393.3 The Bootstrapping Message Flow [TS24.109], modified . . . . . . 393.4 Accessing the AS via the NAF . . . . . . . . . . . . . . . . . . . . 453.5 HTTP Digest Authentication With Bootstrapped Security Associ-

ation [TS24.109], modified . . . . . . . . . . . . . . . . . . . . . . 463.6 Fixed Line GBA Access Without UICC/ISIM With the HTTP to

IMS Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.7 The Authentication Proxy . . . . . . . . . . . . . . . . . . . . . . 503.8 Service Access via HTTP2IMS GW and AP Without GBA-Enabled

Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.9 Functional Architecture for Reference Point Ut [TS23.002] . . . . 543.10 The NAF as AP Replacing Interface Ut [TS33.222] . . . . . . . . 543.11 XML Document Management Architecture [OMAxdm] . . . . . . 553.12 Graphical Representation of the GUSS . . . . . . . . . . . . . . . 57

4.1 USB Smart Card Reader for SIM/UICC cards . . . . . . . . . . . 634.2 The Logical Structure of the BSF Server . . . . . . . . . . . . . . 694.3 The Zh Diameter Message Exchange . . . . . . . . . . . . . . . . 744.4 The Zn Diameter Message Exchange . . . . . . . . . . . . . . . . 754.5 The Ub* Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 764.6 The HTTP2IMS GW Login Page as a Screenshot . . . . . . . . . 774.7 The UID Selection at the HTTP2IMSGW as a Screenshot . . . . 784.8 The Logical Structure of the NAF Server . . . . . . . . . . . . . . 80

xiii

List of Figures

4.9 The Modified GBA Infrastructure for PKI Support and CertificateIssuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.10 The Ua/Ub Client GUI . . . . . . . . . . . . . . . . . . . . . . . . 904.11 The Client GUI After a Successful Ub Interface Run With the BSF 914.12 The Client GUI After a Successful Ub Interface Run . . . . . . . 93

5.1 The Validation Setup Within the FOKUS Open IMS Playground 965.2 The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-

Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 975.3 The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-

Answer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 985.4 The FHoSS GUSS Provisioning Website . . . . . . . . . . . . . . 995.5 The O2 FMC Portal Welcome Page Screenshot . . . . . . . . . . 1015.6 The O2 FMC Portal Offered Web Mailbox Service . . . . . . . . . 1025.7 The FOKUS Open IMS Playground Smart Messenger Demo Screen-

shoot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.8 Wireshark Trace of AP - XDMS Contact List Retrieval Communi-

cation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1055.9 The Decoded HTTP GET and 200 OK Response Flow . . . . . . 106

xiv

List of Tables

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

4.2 Third Party Libraries Used by the BSF Implementation . . . . . . 714.3 Third Party Libraries Used by the NAF Implementation . . . . . 814.4 Mapping of Functional Components to the Java Classes and Projects

of the Implementation . . . . . . . . . . . . . . . . . . . . . . . . 814.5 The Client Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 89

xv

List of Tables

xvi

Chapter 1

Introduction

Due to the variety of communication and access network technologies, nowadaysservices 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 ina secure and trustworthy manner is expected by end users. This influences cur-rent network architectures, while convergence across services, media, and accesstechnologies 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 convergencechallenges and end-user requirements. The IMS is the unified telecommunica-tion industry approach toward an all-IP network architecture that merges theparadigms and technologies of the Internet with the cellular and fixed telecom-munication worlds. It aims at creating a reference service delivery platform forprovisioning IP multimedia services in a reliable, secure, and controllable mannerand was also adopted as the basis of the Next Generation Network (NGN) archi-tecture specified by TISPAN (Telecoms & Internet converged Services & Protocolsfor Advanced Networks).As part of the IMS specification, 3GPP defined a Generic Authentication Archi-tecture (GAA) and the Generic Bootstrapping Architecture (GBA) to addresssecurity issues, especially authentication. The GBA is used to bootstrap a shortterm security association between a client and a server. This is done based on along term security association, that is stored in a tamper resistant module in theclient, as well as at the server side in a central network component such as a HomeSubscriber Server (HSS). The tamper resistant device is usually represented as aUniversal Integrated Circuit Card (UICC). However, this thesis aims at enablingdevices without such a tamper resistant card to access IMS services. Regardless ofwhether the device disposes of the card or not, the long term security association

1

Chapter 1 Introduction

is used to create a short term server-specific security association that can be usedto secure IMS service access. After successful completion of the bootstrappingprocedure, 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 inPre-Shared Key Transport Layer Security (PSK-TLS).The HSS can be seen as the central identity database of an IMS network. Assuch, it contains security values and user profiles. To enable the infrastructureintroduced by this thesis, a subset of the user profile is shared with other IMSnetwork components. This allows for centralized and simple administration andprovisioning of user data, because the system distributes data automatically asnecessary, while maintaining security. Part of this thesis is a Java implementation,which implements the concepts, procedures and mechanisms introduced by thiswork. In the following two sections, the motivation for this work, as well as itsscope are described. The last section assists the reading and understanding of thisthesis 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” 1 in July 2004 as part of the German 3G Beyond NationalTestbed 2. The Fraunhofer FOKUS Open IMS Playground is a testbed that bringstogether all major IMS core components (especially the FOKUS Open Source IMSCore (OSIMS) 3 4), created by Fraunhofer FOKUS and major industry players.The playground is a unique, open and vendor-independent IMS test environmentthat can be used by academic and industrial institutions for early prototyping ofnew IMS related components, protocols and applications, as well as for testingand benchmarking of IMS components. Also, the interconnection to other IMStestbeds is currently under development in order to allow the experience of IMSconcepts and IMS services to be shared with other partners.The mission of the Next Generation Network Infrastructures (NGNI) departmentat FOKUS is to bring different NGN and IMS players together in one singleplace and build a 3GPP compliant IMS environment in order to offer professionalservices in the areas of technical studies, prototype development, infrastructurecomponents, interoperability testing, and integration of new technologies.

1http://www.fokus.fraunhofer.de/ims/2http://www.fokus.fraunhofer.de/national host/index.php?lang=en3http://www.openimscore.org/4http://www.fokus.fraunhofer.de/bereichsseiten/testbeds/ims playground/core.php?lang=en

2

1.2 Scope

NGNI is therefore interested in this thesis, as it actively supports and extendsthe existing IMS playground and service demonstration facilities at FOKUS. Thisthesis also facilitates service access by implementing Single Sing-On (SSO) andprovides 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 projectwith one of the main telecommunications industry players that will use the doc-umented binary prototype version of the Bootstrapping Server Function in theestablishment 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 the2G SIM authentication and the FOKUS Open IMS Playground is a beyond-3Gtestbed. This thesis looks at IMS service level authentication from different angles.It takes into consideration relevant specifications spanning different standardiza-tion organizations including, among others, 3GPP, 3GPP2, ETSI and OMA, whilenot loosing the focus on IMS services and service level authentication. Regardingspecification conformance, this thesis aims at Release 6 specification conformance.Following the horizontally layered OSI model and the Next Generation Networksmodel, this thesis concentrates on the highest layer: the service layer. It willbe investigated how authentication can be achieved in IMS networks, abstractingfrom lower protocol layers.The work includes the design and implementation of a Bootstrapping Server Func-tion, a Network Application Function, a HTTP to IMS gateway and a client appli-cation to demonstrate the bootstrapping procedure. Figure 1.1 shows the scope ofthis 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 adaptionof the 3GPP specified architecture in order to support HTTP clients that do notimplement 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 smallas possible. Service designers should not be limited in creating applications, asthe 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.While changes on the Application Server side are kept to a minimum, this thesis

3

Chapter 1 Introduction

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). CertainApplication servers should not be publicly reachable from the Internet. The Net-work Application Function has been designed to serve the client as the single pointof 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 bythe first chapter.The second chapter, ”Access to IMS Services”, describes the current state of theart and illustrates this work in the broad context of IMS and Next GenerationNetworks. It furthermore states what the IMS actually is and why it is useful. Inaddition, it lists the relevant specifications and gives a first overview of what theGeneric 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. Thisincludes the relevant components, reference points and different operation modesof the Generic Bootstrapping Architecture.The fourth chapter, ”Software Implementation”, describes not only problems thatwere encountered during the design and implementation, but also general prob-lems that result from an insufficient specification, as well as how the problems are

4

1.3 Structural Overview

solved by this implementation. It also describes the implementation features andimplementation decisions. It is intended to provide a detailed description withoutsimply providing a user manual. A Javadoc has been created to serve the codedocumentation 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 FOKUSOpen IMS Playground. This includes a short description of the services testedand 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 theregular chapters such as code snippets, Diameter protocol message formats andnormative procedures that are relevant and interesting for readers with a deeptechnical 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 italicletters together with the source the of the quotation given in square bracketsat 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 fileparameters, 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 blueletters (only in the PDF version of this thesis). After clicking on them, theURL should be opened in your default browser.Example: www.examplepage.org

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

5

Introduction

document viewer should automatically jump to the referenced page in thedocument. 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 viewershould display the page with the referenced entry in the bibliography section.Example: [RFC2617]

6

Chapter 2

Access to IMS Services

The International Telecommunication Union (ITU) defined the IMT-2000 (Inter-national Mobile Telecommunications-2000) for wireless communications networksof the 3rd generation (3G networks). 3G networks combine cellular access tech-nologies with the Internet in order to provide new services. The Internet ProtocolMultimedia Subsystem (IMS) merges different access technologies with the verysuccessful Internet paradigm in order to provide a new user experience wheremultimedia services are available at any time through ubiquitous network access.This chapter will clarify what the IMS actually is, why we need this, and whichkey components are used. At the end of this chapter, the most important speci-fications for this thesis are introduced and shortly discussed. Standardization isvery important in todays fast changing telecommunication environments in orderto 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 providingmultimedia services. It is based, among others, on the standard Internet Protocol(IP) [RFC791] [RFC2460], the Session Initiation Protocol (SIP) [RFC3261] andthe 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 usedtoday for transporting voice and video in fixed and mobile networks. The CS do-main is mainly characterized by the dedicated communication path between twostations which is a connected sequence of links between network nodes. There is

7

Chapter 2 Access to IMS Services

a call-setup phase in which bandwidth is reserved for this connection on all nodeson 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 thebandwidth has been reserved and cannot be used by other parties that share thesame network. The advantage resulting from using CS technology is a guaranteedquality of service (QoS).PS technology has been recognized to be a more efficient way of sharing networkbandwidth. The Internet is based on PS technology. In PS, data is transmittedin short packets. Usually, there is an upper bound on the packet length. If thesender has longer messages to send, the data is split into a series of packets withthe maximum length. Each packet contains signaling data which is used to routethe messages to the right destination. There is no call-setup phase, messages aresend right away, each of them containing the destination address. Based on therate 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 theconnection at a certain time. The drawback from PS is that the communicationpath is not reserved. It is therefore difficult to guarantee a certain QoS. UsuallyPS 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 IMScomes into play. By employing the IMS QoS mechanisms, QoS can be assuredalthough using PS technology. This is the first reason why IMS is needed butthere are more. The following description gives an overview over the main reasonswhy the IMS is needed:

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

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

8

2.2 Service Deployment Based on a Layered Architecture

Integration of different services As interfaces in IMS are standardized, servicedevelopers can create many different compatible services that run on IMSplatforms. This provides operators with a large services portfolio that can beenriched by implementations of many different vendors. Of course, operatorscan also employ services yielded by own development. However, servicediversity is also beneficial for end users, because every user can choose froma variety of services, only using and paying for those, that best fit its personalneeds. Furthermore, the IMS can provide existing Internet services, that arealready known to the users from browsing the web.

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

Apart from the reasons mentioned above, which are beneficial to operators as wellas end-users, another reason for operators to run the IMS is obvious: Internetservices like Skype threaten the business of the operators. The danger resultingfrom such services is that the operators’ business might be reduced to simplysupplying the ”bit pipe”. Imagine, for example, flat rates for mobile telephonyand 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 athird party and is outside the reach of the operator. The assumption today inthe telecommunication sector is that in the near future the money will be madewith (multimedia) services and content rather than plain telephony. This is whya central reason for the operators to deploy IMS today, is to generate revenue inthe future by keeping control of the network and especially the services that willbe run over their own networks. Therefore, IMS can be seen as the last chancefor the operators to prevent the ”bit pipe” scenario and deploy a standardizedand controllable infrastructure. If this last unified approach fails, if the IMS fails,the operators are likely to merely provide network access, while Internet servicecompanies like Google, Yahoo, Skype, etc. are in control of the services.

2.2 Service Deployment Based on a LayeredArchitecture

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

9

Chapter 2 Access to IMS Services

services. Well defined interfaces between the layers enable operators, R&D insti-tutes and vendors to profit from an industry spanning interoperability. In figure2.1 the different layers are shown. They will be discussed in the following.

Services

Session Control

IMS

AccessLayer

UMTSWLAN

xDSL

...

Figure 2.1: The NGN Layered Architecture

Access Layer The access layer represents any network that transports IP trafficin 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 layeris 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 (pleaserefer to the Bibliography section for the web sites’ addresses).For this thesis, it will simply be assumed that we are able to use any devicecommunicating 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 firsttime to the network using appropriated protocols depending on the accesstechnology.

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

10

2.2 Service Deployment Based on a Layered Architecture

[CxA] and [CxB]. In fixed line access, most terminals are missing a Univer-sal Integrated Circuit Card (UICC) which hosts the Universal SubscriberIdentity 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 realizedby the IMS core components on the service control layer. Please note thatsession handling is not necessarily required. The Internet for instance doesnot employ session handling. In the case of the IMS however, SIP trafficis controlled by the IMS core network elements on this layer of the overallNGN architecture. This enables full control of a session and features likecharging and Quality of Service.

Service Layer This layer gathers different kind of services. This includes homeoperator 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 fieldof research and specification efforts. By the end of this chapter, the readershould understand what the main problems in service layer authenticationare, 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 theother layers. This does not have to be true for all services, an example mightbe the T-Online Number which is used on the access layer to grant access tothe Internet but can be reused on the service layer to access services offeredvia 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 sensiblekind of data. The user is interested in keeping the amount of credentialsneeded for different sites as small as possible. The danger resulting fromreusing the same credentials for different services or storing credentials indigital 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, withoutcompromising security. There are different approaches to realize SSO andthe 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. Thenext section describes the IMS core network elements and the Generic Boot-strapping Architecture which has been implemented as part of this thesisand which handles service layer authentication and authorization.

11

Chapter 2 Access to IMS Services

2.3 The IMS Architecture and Its Core Components

This section introduces the most important IMS components. As the IMS is acomplex architecture with a number of different elements, only those parts relevantto the service layer authentication and authorization process will be discussed indetail. Please refer to figure 2.2 for an overview of the most important IMScomponents.

HSS

P-CSCF

S-CSCF

I-CSCFIMS Client on Mobile Phone

ApplicationServer

Media Server / Media Gateway /Signaling Gateway

AccessNetwork

AccessNetwork Legacy

Networks(GSM, PSTN)

P-CSCF Cx

Mw

Mw

Mw

Mw

Mw

Cx

ISC

Sh

Mi

Gm

Fixed LineWorkstation

Figure 2.2: The Simplified IMS Architecture

CSCF The CSCFs (Call Session Control Function) are SIP servers that handleSIP-based traffic in IMS networks. Being SIP agents, they are central com-ponents of every IMS as they process the SIP signaling. At FOKUS theCSCFs 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-CSCF) and S-CSCF (Serving-CSCF). All CSCFs arebasically 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 requirementsdictated by its particular function (P-, I- or S-).

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

1http://www.iptel.org/ser

12

2.3 The IMS Architecture and Its Core Components

server. This means that all the requests initiated by the IMS terminalor destined for the IMS terminal traverse the P-CSCF. [camarillo]

• I-CSCF: The Interrogating-CSCF is a SIP proxy located at the edge ofan administrative domain. The address of the I-CSCF is listed in theDNS (Domain Name System) records of the domain. [...] The I-CSCFretrieves user location information and routes the SIP request to theappropriate 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 controllas well. In addition to SIP server functionality the S-CSCF also actsas a SIP registrar. This means that it maintains a binding between theuser 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 UserIdentity). [camarillo]

HSS The HSS in 3G IMS is an evolution of the Home Location Register (HLR) inGSM (Global System for Mobile Communications). It stores subscriber pro-file data (including Public and Private User Identity), service and chargingprofile data, filter criteria (for choosing an appropriate application server)and corresponding service trigger point information, and can be seen as thecentral AAA (Authentication, Authorization, Accounting) data base withinthe IMS architecture. The HSS also is a central component of the GenericBootstrapping Architecture (GBA) as depicted by figure 2.3. The GBA, be-ing the main focus of this thesis, will be explained in the following sections.At this stage it is sufficient to know, that the HSS stores information suchas a shared secret (between user and HSS) and other authentication andauthorization information which can be used by the GBA components togrant (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 applications. Usuallythese applications are access restricted and secured by some kind of loginprocedure where access is granted to subscribed users only. The idea of theGBA is to relieve the ASs from security tasks on and reuse the authentica-tion and authorization information stored in the HSS for AS access decisionson the HTTP layer. In SIP communication the user identity is carried ina P-Asserted-Identity field. By using the GBA, the user identity canbe inserted into requests toward the ASs in a X-3GPP-Asserted-Identity

HTTP header.

13

Chapter 2 Access to IMS Services

Application servers can offer a predefined suite of services but can also offera 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 ResourceFunction Control (MRFC), Media Resource Function Processor (MRFP),Media Gateway Control Function (MGCF), Media Gateway (MGW) andMedia 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 onecomponent as depicted by figure 2.2. The function of all of the above is todeliver (e.g. announcements), mix (e.g. conference calls), and control me-dia streams and connect the IMS to the PSTN (Public Switched TelephoneNetwork) and legacy networks. This includes low level functions like pro-tocol conversion between legacy protocols (e.g. ISUP) and the IM domaincall control protocols, choosing the correct CSCF depending on the routingnumber 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) areinterfaces 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 Diameterintra-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 GBArelevant reference points will be discussed in more detail in the followingsections.

This section should have provided you with a broad overview of what the coreIMS elements are and why they are needed. The next section describes the HTTPprotocol.

2.4 The Hypertext Transfer Protocol

As the Hypertext Transfer Protocol (HTTP) is a well-known protocol, it will bedescribed 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

14

2.5 The Generic Bootstrapping Architecture

used to carry web site information and data in the World Wide Web. Web browserssupport 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 relevantinformation such as employed user-agent, encoding information, content-length,content type, etc. The message content (for example a HTML Web site) is carriedin the HTTP body.HTTP defines a set of request methods (GET, POST, PUT, HEAD, etc.) thatindicate the intended action to be performed at the receiving server. It further-more specifies numeric response status codes and textual response phrases, thatindicate the result of the request.Authentication for HTTP has been specified in [RFC2617]. HTTP supports Ba-sic and Digest Access Authentication. The Basic Authentication Scheme is notconsidered to be secure as user name and password are transmitted in cleartext(if no transport security is used). The Digest Scheme is based on cryptographichashes and can be used in the Generic Bootstrapping Architecture between theclient and a Network Application function.

The next section introduces the Generic Bootstrapping Architecture and shouldgive you - based on the understanding of the layered architecture and the IMSelements - 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 sharedsecrets and implements an authentication proxy in order to serve all applicationsthat 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. Figure 2.3 shows the GBA architecture and how it fits into the overallIMS architecture. The GBA consists mainly of two new elements: the Bootstrap-ping Server Function (BSF) and the Network Application Function (NAF). UEin 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

15

Chapter 2 Access to IMS Services

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 onthe layered architecture of NGNs and how the GBA fits into this approach. Aspreviously described, the vertical structure of NGNs consists of three layers. Theaccess 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 theservice 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

ZhZn

BSF

NAF

HSS

P-CSCF

S-CSCF

I-CSCF

UE

ApplicationServer

Media Server / Media Gateway / Signaling Gateway

AccessNetwork

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 theconcept, rather than trying to allocate network elements to concrete layers. This

16

2.5 The Generic Bootstrapping Architecture

means that the overall IMS architecture with CSCFs et cetera - being a sessioncontrol system - is located in the session control layer. Following this logic con-sequently, the GBA - being a service access supporting system - is located in theservice layer. In order to avoid network components to be depicted twice (likeHSS, AS, and UE) the connectors span multiple layers. This implies that theGBA part of figure 2.4 (service layer) can itself be split into different layers, buttaken 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 aswell as the interworking of these components with the existing elements such asHSS and AS:

BSF The Bootstrapping Server Function (BSF) has three interfaces: Ub, Zn andZh. It is publicly reachable from the Internet on the Ub interface, whereasthe interfaces Zn and Zh are only accessible from within the operators net-work. The BSF can also be configured to accept requests from outside ofthe operators network on the Zn interface, but at this stage the BSF shallbe assumed to communicate with NAFs from within the operators networkonly.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 theBSF 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 aDiameter 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 actsas a HTTP/S server. On the Zn interface it communicates with the BSFexchanging Diameter messages. The connection with the AS is also a HTTPconnection. Optionally this connection can be secured. This also depends onthe location of the AS. At this stage it shall be assumed that the AS is locatedwithin the operators network and is not publicly reachable from the Internet.Therefore no further security measures are necessary on this interface. If theconnection has to established via untrusted networks, confidentiality andintegrity protection can be provided using NDS/IP mechanisms as specifiedin [TS33.210]. Because the AP terminates the TLS tunnel from UE, it isalso possible to establish a TLS tunnel with ASs.

UE The User Equipment (UE) must support HTTP(S) in order to communicate

17

Chapter 2 Access to IMS Services

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

In the setup for this thesis it will be assumed that the HSS and the ASs residewithin the operators network and cannot be reached from the Internet. The BSFand 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 ownsecurity measures on these interfaces.

It will now be described in detail how the GBA works and which messages areexchanged. Note that the following chapters also provide detailed information onthe bootstrapping procedure. The following first description is given to introducethe 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 NAFHSS

1. GET2. 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. GUSS13. 200 OK

Figure 2.5: The General Bootstrapping procedure

18

2.5 The Generic Bootstrapping Architecture

1. GET: this is a HTTP GET transfered over interface Ua. In this first stepthe user requests a web page residing on an AS, which is hidden behindthe NAF. The NAF acts as a reverse proxy. This means that requeststargeting an AS will be directed to the NAF due to DNS and networkconfiguration. An example: The user enters http://service.open-ims.

org/service in his web browser in order to access his favorite service. Dueto DNS configuration service.open-ims.org will be resolved to the IPaddress of the NAF. The browser is therefore sending the request to theNAF. This is why the sequence chart shows no application servers. Untilthe 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 userhas already been authenticated. This is done by checking for cookies (thatshould previously have been set by the NAF if the user has already beenauthenticated) and checking for special HTTP headers, that would havebeen set by a GBA-capable client in order to demonstrate that successfulauthentication has already taken place. If authentication has not takenplace yet, the NAF redirects the client to the BSF, where the bootstrappingprocedure begins.

3. GET: The client accesses the BSF following the redirect by the NAF. Thisis interface Ub communication. Note that this step actually consists ofof two other steps. The user first accesses the BSF which denies furthercommunication, 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) fromthe HSS over reference point Zh for the user identifier that has been obtainedfrom the client in the previous step. This is Diameter communication. TheDiameter protocol itself and the exchanged messages will be discussed in alater section. The Authentication Vectors consist of a nonce (number usedonce) value, a respected response value XRES and further security values.Additionally, Generic User Security Settings (GUSS) are transfered fromthe HSS to the BSF. The GUSS carry user identities that are recognized atthe AS, and authorization values, which can be transfered to the NAF. TheNAF can decide - based on the GUSS data - if a user is authorized to use acertain type of service.However, at this stage the BSF requests the Authentication Vectors whichare needed to challenge the client and proceed with the authentication.

5. Vectors: The HSS returns the Authentication Vectors for that user. Thiscontains the expected response from the client XRES. The BSF will check the

19

Chapter 2 Access to IMS Services

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 digestis hash value. Hash values are generated by hash functions which providea method of turning some kind of data into a hexadecimal notation whichcan then be handled by computers. A good hash function does not providethe same number for different input data with a very high probability. Thedigital fingerprint can then be called unique and servers as an unique iden-tifier.The authentication vectors furthermore contain parts of the key materialthat 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 theclient need to be able to generate the response RES by applying the IMSAuthentication 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 fromthe BSF. The RES is only identical to the expected XRES if the client is inpossession of the nonce and the secret shared between the client and theHSS (the secret need to be agreed during IMS contract establishment). Fora detailed description of the algorithm by which the RES is calculated pleaserefer to [TS33.102] and [TS35.205]. A digest of the calculated value RES issend to the BSF.The client furthermore calculates the key material Ks NAF used for referencepoint Ua security mechanisms.

8. if RES = XRES: The BSF verifies that the client calculated digest of the valueRES matches the digest of the expected response XRES and that the clientmust therefore be in possession of the correct secret key. Note that by usingthis security mechanism, the secret (which is only known by HSS and UEand which is even unknown to the BSF) is never actually transfered overthe potentially insecure communication path.If the values are identical, the client is allowed further communication withBSF and NAF. In case of failure, a HTTP 401 Unauthorized (carrying thenonce 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 coversdifferent approaches of how successful authentication is demonstrated to theNAF. This can be done by setting special HTTP headers (this requires a

20

2.6 The Standardization Organizations and Specification Impact

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

10. GET: The client follows the redirection back to the NAF. It now needs todemonstrate to the NAF that is has successfully authenticated with the BSF.This can be done by applying the HTTP Digest mechanism [RFC2617] or theNAF 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 overreference point Zn. This is Diameter communication.

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

13. 200 OK: The client is allowed to access the AS through the NAF. The NAFacts as a reverse proxy and all requests between client and AS go throughthe NAF. This enables service developers to forget about authenticationand channel security. The NAF (with support from the BSF) handles au-thentication, authorization, and channel security and relives the connectedapplications 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 BootstrappingArchitecture is and why it is needed. The next section will introduce the stan-dardization organizations that are important for this thesis and briefly discuss thespecifications that provide the basis for the implementation.

2.6 The Standardization Organizations andSpecification Impact

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

21

Chapter 2 Access to IMS Services

2.6.1 Third Generation Partnership Project

The Third Generation Partnership Project (3GPP) 2 was established in December1998 by the signing of ”The 3rd Generation Partnership Project Agreement”. Itis a collaboration agreement that unifies telecommunications standards bodiesknown as ”Organizational Partners”. These Organizational Partners currentlyinclude:

• 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 UMTSForum 10, 3G Americas 11, the IPv6 Forum 12, and more. Note that this is not anexhaustive list.3GPP was established to publish technical specifications. Its original scope was:”to produce globally applicable Technical Specifications and Technical Reports fora 3rd Generation Mobile System based on evolved GSM core networks and theradio 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.html4http://www.etsi.org/5http://www.ccsa.org.cn/english/intro.php6http://www.atis.org/7http://www.tta.or.kr/English/new/main/index.htm8http://www.ttc.or.jp/e/index.html9http://www.gsmworld.com/index.shtml

10http://www.umts-forum.org/servlet/dycon/ztumts/umts/Live/en/umts/Home11http://www.3gamericas.org/English/index.cfm12http://www.ipv6forum.org/

22

2.6 The Standardization Organizations and Specification Impact

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

The following list introduces the main 3GPP specifications that are relevant tothis 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 applications share this common need for a peerauthentication mechanism, it has been considered useful to specify a GenericAuthentication Architecture (GAA). This GAA describes a generic archi-tecture for peer authentication that can a priori serve for any (present andfuture) application.” [TS33.919] This document describes the framework forthe GAA and how the different building blocks are combined to provide asecure 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 andtransmitted 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 isto create a security association between UE and BSF for further usage inGAA applications. The purpose of the Ua interface is to use the so createdbootstrapped 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 whichprovides 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.This document specifies the Zh, as well as the Zn interface, which are both

23

Chapter 2 Access to IMS Services

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

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 August2006 and many details are still missing. This is why it currently has noimpact on the implementation. It is a functional add-on for the GAA.The GBA Push Function is a mechanism to bootstrap a security associationbetween the NAF and the UE, without forcing the UE to contact the BSF toinitiate the bootstrapping procedure. ”The adoption of GAA by other stan-dardization bodies showed that some services can not make the assumptionthat the User Equipment (UE) has always the possibility to connect to theBootstrapping Server Function (BSF). Hence, this specification introducesand 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 broadoverview of the specification spectrum. Please refer to [TS33.223] for moredetails 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 andInternet Explorer browsers only.

3GPP TS 33.920 [TS33.920], SIM card based Generic Bootstrapping Architec-ture (GBA) Early implementation feature.”3GPP defined the Generic Bootstrapping Architecture (GBA) in Release6. 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 ishigher than the 2G SIM authentication. On the other hand, there are morethan one billion people with SIMs in their phones and it will take long timeto provision UICCs capable of 3G authentication to such a large population.Meanwhile there should be a way to offer services whose authentication isbased on GAA also to 2G subscribers. [...] It should be noted that the workoutlined 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 2GGBA.” [TS33.920]This thesis concentrates on 3G GBA and does not implement 2G GBA.

24

2.6 The Standardization Organizations and Specification Impact

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 Americanand Asian cellular networks based on ANSI/TIA/EIA-41 standards and especiallyCDMA2000 radio access into a 3G system. 3GPP2 is very similar to 3GPP inits structure and scope. Like 3GPP it is a partnership project of organizationalpartners. ”Although discussions did take place between ETSI and the ANSI-41community with a view to consolidating collaboration efforts for all ITU ”familymembers,” in the end it was deemed appropriate that a parallel Partnership Projectbe 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-developingbody, providing easier access of the outputs into the ITU after transposition of thespecifications in a Standards Development Organization (SDO) into a standardand submittal via the national process, as applicable, into the ITU.” [www3GPP2]Most of the organizational partners of 3GPP2 are also organizational partners of3GPP. 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 Group 15, theIPv6 Forum, the International 450 Association (IA 450) 16, and MobileIGNITE17.

13http://www.3gpp2.org/14http://www.tiaonline.org/15http://www.cdg.org/16http://www.450world.org/17http://www.mobileignite.org/

25

Chapter 2 Access to IMS Services

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

S.S0109-0 v1.0 [S.S0109], Generic Bootstrapping Architecture (GBA) Frame-work.This document describes the GBA, its security features, and the generalmechanism to bootstrap key material for application security. This includesan architecture overview, architecture requirements, and the detailed pro-cedure how to bootstrap credentials similar to [TS33.220]. Note that theimplementation of this thesis will concentrate on conformance to the 3GPPspecifications 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 havebeen 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, butwill not be realized by the implementation.

2.6.3 ETSI / TISPAN

The European Telecommunications Standards Institute (ETSI) 18 is a standard-ization organization of the telecommunications industry in Europe. It was createdin 1988 and is an independent and non-profit organization with worldwide pro-jection. Its mission is to produce telecommunications standards for today and forthe future. ETSI has done so by, for example, standardizing the GSM cell phonesystem.ETSI has 699 members from 55 countries inside and outside Europe. This in-cludes, among others, manufacturers, service providers, network operators, andresearch 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) 19 is specializing infixed networks and Internet convergence. TISPAN was created in 2003 from thefusion 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 (IPMultimedia Subsystem), TISPAN and 3GPP are now working together to define

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

26

2.6 The Standardization Organizations and Specification Impact

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 telecombusiness model for both fixed and mobile network operators. Access independentIMS will be a key enabler for fixed/mobile convergence, reducing network instal-lation and maintenance costs, and allowing new services to be rapidly developedand deployed to satisfy new market demands. NGN Release 1 was launched byTISPAN in December 2005, providing the robust and open standards that industrycan use as a reliable basis for the development and implementation of the firstgeneration of NGN systems. TISPAN is now working on Release 2, with a focuson enhanced mobility, new services and content delivery with improved securityand 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 doesnot define application/service layer access but explicitly names the 3GPPGAA and GBA Bootstrapping for application layer security.Figure 2.6 gives a high level overview over the TISPAN security architecturewhich includes authentication on all layers. This thesis focuses on the service

ISIM AKA mode

NASS Authentication(e.g. IEEE 802.1x/PANA

NASScredentials

ISIM GBA -U mode

V - UAAFAMF 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 3GPPGAA/GBA, the 3GPP specifications, that have already been introduced insubsection 2.6.1, are also relevant within the TISPAN/NGN context.

ETSI TS 183 033 [ETSI183033], Diameter based protocol for the interfaces be-tween the Call Session Control Function and the User Profile Server Func-

27

Chapter 2 Access to IMS Services

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 arethe 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 researchand development consortium that was founded in 1988 and contains more than45 members. The members are cable television system operators. CableLabs’sobjective is to support its members in integrating technical advancements in cabletelecommunications technologies into their business objectives and enable inter-operability among various cable systems.”CableLabs received copyright licenses from the ETSI to reproduce, modify, anddistribute the 3GPP specifications contained in the PacketCable IMS Delta Specifi-cations. CableLabs will submit these enhancements to the 3GPP for incorporationinto 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 specificationsand have been modified by CableLabs for the benefit of the cable industry. The3GPP 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 bootstrappingarchitecture Specification 3GPP TS 33.220.This document introduces new HTTP Digest Over TLS enhancements tothe Generic Bootstrapping Architecture. This is referred to as GBA H. Thebootstrapping procedure starts by establishing a TLS tunnel between theUE and the BSF. This is server side authenticated TLS. The UE authenti-cates the BSF by the certificate presented by the BSF. After establishing theTLS tunnel, the HTTP Digest mechanism is used to derive the key materialbetween the UE and the BSF.This additional specification allows the UE to bootstrap the session keys

20http://www.cablelabs.com/

28

2.6 The Standardization Organizations and Specification Impact

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 andalgorithm to allow the BSF to calculate a challenge.The Fraunhofer Home Subscriber Server (FHoSS) used in the Open IMSPlayground 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 Interfacesbased 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 mobileoperators, device and network suppliers, information technology companies, andcontent and service providers. The OMA aims at developing market driven, in-teroperable mobile service enablers. The term ”service enabler” generally standsfor a technology to be used in the development, deployment or operation of aservice, so as to ”enable” the service. It is usually defined in a specification, ora set of specifications. The OMA publishes such service enabler specifications,as for examples: presence enhanced communication, location services, and groupmanagement.OMA was formed in June 2002 and has so far integrated the following organi-zations: Location Interoperability Forum (LIF), WAP Forum, Mobile GamingInteroperability 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 interoperabilityacross 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 andsupporter members. The member companies include mobile operators, informa-tion technology companies, wireless vendors, and content provider. The impressiveup to date list of current members including IBM, Microsoft, Nokia, and manymore, can be obtained from the official OMA website 21.

21http://member.openmobilealliance.org/Common display/currentmembers.asp

29

Chapter 2 Access to IMS Services

Furthermore, OMA embodies a new type of organization ”that harmonizes dis-parate industry activities and accelerates the delivery of mobile service enablerspecifications and interoperability testing. In this role, OMA has embraced the ob-jective of reducing fragmentation in the mobile standards industry. To effectivelyaccomplish this, OMA has established two distinct programs, the OMA AffiliateIntegration Program and the OMA External Liaison Program. These programsallow OMA to embrace the entire mobile industry either by working to integratethe work of other organizations into the OMA Technical Plenary Working Groupsor by building formal relationships with other standards bodies or similar type or-ganizations.” [wwwOMA] The members of the collaboration programs, including3GPP and 3GPP2, ETSI, ITU-T, OASIS, W3C, and many more, can also be ob-tained from the official OMS website 22.The following list introduces specifications that are related to this thesis:

OMA-AD-XDM-V1 0-20060612-A [OMAxdm], XML Document ManagementArchitecture.This document provides an overview of the XML Document Management(XDM) enabler including logical entities and reference points between them.The OMA Aggregation Proxy is introduced by this document which can actas an Authentication Proxy in a 3GPP sense or as an AS behind an Au-thentication Proxy. The next document in the list gives more informationfor these two roles that can be played by the OMA Aggregation Proxy. Thesecurity architecture relies on TLS in order to provide integrity and con-fidentiality protection. However, for a 3GPP realization, the GAA, as anunderlying network mechanism, is used as specified in [TS33.222] to providethe XDM service security if GAA is present.

OMA-TS-XDM Core-V1 0 1-20061128-A [OMAap], XML Document Manage-ment (XDM) Specification.This document gives more details on how the Aggregation Proxy operateswith and without combination of the 3GPP GBA. The OMA Aggregationproxy can replace the 3GPP Authentication Proxy (AP) or can reside behindsuch an Authentication Proxy. In the latter case, it acts as a usual HTTPApplication Server, supporting 3GPP GBA in the sense that the specialHTTP headers inserted by a 3GPP AP will be recognized and analyzed ac-cordingly. More on the OMA Aggregation proxy and GBA interworking canbe found in section 3.6.

OMA-Draft-TS-GBA-Profile-V1 0-20051215-D [OMAgba], OMA GBA Pro-

22http://www.openmobilealliance.org/collaborating/index.html

30

2.6 The Standardization Organizations and Specification Impact

file Draft Version 1.0.As the 3GPP GBA is sometimes used in OMA Enabler Specifications, thisspecification defines an OMA profile of the GBA. The OMA GBA Profile isbased on the 3GPP GBA and specifies that all OMA GBA Profile compliantimplementations must also conform to 3GPP GBA specifications. 3PP2 iscurrently also specifying GBA procedures. The OMA GBA Profile draftexplicitly states that as soon as the GBA specifications in 3GPP2 are ap-proved, they should be taken into consideration by the OMA specification.The OMA GBA Profile aims at avoiding interoperability problems with GBAusage in OMA Enablers that might be caused by the existence of several op-tions in the GBA specifications. OMA Workgroups are recommended toemploy the OMA GBA Profile when developing enabler specifications. Theprofile can for example require OMA enablers to use some specific optionsin the TLS protocol. This increases the level of security (compared to onlyimplementing the mandatory features) and interoperability.”The intention is to create a secure and interoperable GBA that can be re-used without the need to define the profile for GBA separately in each OMAEnabler specifications.” [OMAgba]

In addition, there are other OMA specifications that briefly reference the GAAsuch as the Presence SIMPLE Architecture 23 which relies on ”external authen-tication and authorization done for the Presence Sources and Watchers. Whenrealized with 3GPP IMS or 3GPP2 MMD networks, GAA [3GPP TS 33.222] canbe used for that purpose, acting as an Authentication Proxy”.

2.6.6 Advances to IP Multimedia Subsystem (A-IMS)

A-IMS is a joint initiative by Verizon Wireless and five of its major equipmentsuppliers: Cisco Systems, Lucent Technologies, Motorola, Nortel, and Qualcomm.Driven by Verizon Wirless, the six companies published a document outliningadvances to the 3GPP/3GPP2 specified IMS/MMD. A-IMS claims to be the evo-lution of existing IMS and MMD standards, but has so far not been standardizedin any way. However, it is Verizon’s intention to submit the A-IMS work to stan-dardization. The major benefits from A-IMS described by the A-IMS authorsare:

Support of both SIP and non-SIP services A-IMS aims at allowing control overSIP and non-SIP support for certain capabilities. The capabilities include

23http://member.openmobilealliance.org/ftp/Public documents/PAG/Permanent documents/

31

Chapter 2 Access to IMS Services

accounting, authorization, authentication, policy controls, service control,application interaction, roaming/peering, QoS management, and security.However, it does not become very clear how to achieve advances to all ofthe outlined capability controls as, for example, a major strength of IMS isthe support of Diameter and therefore AAA (authentication, authorization,accounting) support.

Management of services for business customers ”In the future, A-IMS couldbe enhanced to allow the business (or consumer) customer to run a VPNbetween their client and the home network, while still giving the carrier thecapability to provide QoS.”[AIMS]

Integrated end-to-end security A-IMS introduces new network components (seefigure 2.7) such as the Security Operations Center and a Security Manager.A-IMS claims to have countermeasures against Denial of Service (DOS) at-tacks, and security breaches from inside and outside the carrier network.This is done via intrusion detection/prevention and discovery, and mitiga-tion of signature based attacks.”In A-IMS, an Integrated Security System searches for anomalies from insideand outside of the network, and addresses those anomalies. The architec-ture is unique in that security is designed in, versus overlaid, and providedin a layered approach, with all elements of the network being protected frommalicious attacks and capable of detecting malicious activity and managingit.” [AIMS]

Focus on Mobile Voice A-IMS claims to optimize ”voice latencies, while at thesame time providing the operator the ability to manage and control thevoice traffic.” [AIMS] Also inter-operator and inter-technology handoffs arepromised to be supported reducing handoff times.

The A-IMS architecture provides the above benefits by enhancing the currentIMS/MMD architecture and by adding some new elements. In the following, theA-IMS network elements will shortly be described. Please refer to figure 2.7 foran A-IMS network overview. The major elements of A-IMS are an ApplicationManager, a Services Data Manager, a Bearer Manager, a Security Manager, anda Policy Manager which function as follows:

Application Manager (AM) This element is similar to the IMS CSCFs and alsoperforms PSTN routing.

Services Data Manager (SDM) This component is similar to the IMS HSS. It

32

2.6 The Standardization Organizations and Specification Impact

Non-SIP AS

RegulatoryServers

RegulatoryServers

RegulatoryServers

PSTNGateway

MediaServers

BTS RRM

PSTN

SS7

Managed IP/ Other IP Network

ANSI-41Networks

Broadband Networks

EnterpriseNetworks

OtherNetworks

SIP AS

SIP AS

Web Services Web

Services Specific Non-SIP

To Other Networks/ Services

To SOC

(Security Operations Center)

To Clearing Houses

Policy Manager

Bearer Manager

Security Manager

Presence

Services Data

Manager

ApplicationManager

ServiceBroker

Non-MMD Networks

AT

IPGW

Figure 2.7: The A-IMS Architecture Overview [AIMS]

is the central data repository for both SIP and non-SIP services.

Bearer Manager (BM) A-IMS supports bearer layer control. Service control in-cludes the SIP and IP layer of the network. The BM is a security enforcementand mobility anchor point. It can furthermore been seen as the policy en-forcement point for QoS, accounting, Packet Flow Optimization (PFO), andmobility/access policies.

Security Manager (SM) The SM monitors network activity and can detect anoma-lies. This is done based on programmed algorithms. Once a thread has beenrecognized, the SM responds to the thread in an appropriate way. The SMis the central component of the the Security Operations Center (SOC).

Policy Manager (PM) The PM provides ”unified management services of notjust QoS and accounting, but also Packet Flow Optimization (PFO), mo-bility and access controls. The PM also links the conditions in the networkto the behavior of applications that run on the network. This allows theoperator to truly manage the way in which the network ultimately supportsthe applications it supports. To accommodate the realities of system migra-tion, the Policy Manager is flexible enough to implement device-specific or

33

Chapter 2 Access to IMS Services

application-specific interfaces.” [AIMS]

Although A-IMS has not been standardized yet and does not have a direct impacton the GBA or its components, it addresses security to some extend (as the GBA)and is therefore an issue that might need to be taken into consideration in thefuture. At this stage, being a proprietary proposal rather than an open standard,A-IMS does not seem to experience the necessary industry support to become acrucial issue.

2.7 Summary

This chapter outlined what the Generic Bootstrapping Architecture actually isand how it fits into the overall vision of an IP Multimedia Subsystem. You shouldnow be familiar with what the IMS is and why it is beneficial for the telecommu-nication industry as well as the end users.It should furthermore have become clear which standardization organizations pub-lish specifications that are relevant to this thesis and which specific documentshave been taken into account for the realization of the implementation.The next chapter will discuss the components of the GBA and their interworkingin more detail. Also, it will give insights into the design decisions made in orderto build an infrastructure that serves as a secure authentication and authorizationsystem and actively supports the Application Servers.

34

Chapter 3

Infrastructure Design andRequirements

This chapter describes the bootstrapping procedure in a very detailed way. Tostart with, the two different ways of approaching the GBA are discussed: GBAusage with a mobile device and UICC (Universal Integrated Circuit Card hostingthe ISIM) support, and GBA usage without UICC or mobile device. The messagesflows and involved components in either case will be outlined. Also, the Diameterprotocol will briefly be introduced. At the end of this chapter the role of the GUSSand the interworking with the OMA XDM architecture will be described.

3.1 2G GBA, GBA ME and GBA U

The latest Release 7 versions of [TS24.109] and [TS33.220] define support of a 2Gbootstrapping procedure. This allows the use of SIM cards or SIMs on UICC forGBA. This is only useful for operators that have not yet fully deployed USIMs.This thesis’s implementation does not support 2G GBA as it is deployed in theFraunhofer FOKUS Open IMS Playground ([wwwTestbed]) which is a 3G beyondTestbed. Also, this thesis aims at Release 6 conformance. Please note that, apartfrom BSF and NAF, the HSS connected to the BSF needs to support 2G GBAas well. For example, a HSS-internal interface to the 2G Authentication Center isneeded for returning 2G Authentication Vectors upon Zh requests from the BSF.The mobile equipment (ME) utilized by the user to access the GBA need tosupport the GBA bootstrapping procedure, which means that there need to be afunction on the ME than can execute the bootstrapping procedure with the BSF.Put another way: the ME need to support the Ub reference point. Furthermore,the ME need to support the reference point Ua in order to use the key material

35

Chapter 3 Infrastructure Design and Requirements

(obtained from running the bootstrapping procedure) with the NAF. There aretwo different cases of the the GBA: GBA ME and GBA U.

GBA ME This is the ME-based GBA, where all GBA-specific functions are car-ried out in the ME. In this case the UICC is GBA-unaware. Please notethat in the following, whenever the term ”GBA” is used without any furtherqualification, then this refers to GBA ME.

GBA U This is the UICC-based GBA which means that GBA is employed withUICC-based enhancements. This will further be clarified in the following.For the moment it is sufficient to understand, that in GBA U, the GBA-specific functions are split between ME and UICC.

3.2 The Diameter Protocol

Diameter is a new IETF protocol for Authentication, Authorization and Account-ing (AAA) services and is specified in [RFC3588]. It uses TCP for message trans-port and has an explicit modular structure which makes it highly extensible. Themodular structure is achieved by the definition of a base protocol ([RFC3588])which can be extended by applications in a plug and play fashion.A Diameter message usually carries an arbitrary number of Attribute Value Pairs(AVP). The function of an AVP can be compared to that of a HTTP header. Itis an information element carrying some value that might be of interest for thereceiving party. An example might be a username AVP that carries some user iden-tifier. Figure 3.1 shows the format of a Diameter message and the correspondingAVPs.

Version The Version field is set to the used Diameter version (currently the firstversion).

Message length The Message length field indicates the length of the Diametermessage including the header fields.

Flags The flags can be set to R(equest), P(roxiable), E(rror), or T (potentiallyre-transmitted message). The remaining flag bits are reserved for future use.

Command Code The Command Code field carries the command code assignedto this message. The address space is managed by IANA.

36

3.2 The Diameter Protocol

Version Message length

Flags Command Code

Application ID

Hop-by-Hop ID

End-to-End ID

AVP code

AVP Flags AVP Length

Vendor ID for the AVP (optional)

AVP value

AVP code...

0 8 16 31

Figure 3.1: The Diameter Message Format [RFC3588]

Application ID The Application ID field holds the identifier value of the appli-cation the message is applicable for. This can also be a vendor specificapplication.

Hop-by-Hop ID [...]aids in matching requests and replies. The sender MUSTensure that the Hop-by-Hop identifier in a request is unique on a given con-nection at any given time, and MAY attempt to ensure that the number isunique across reboots. The sender of an Answer message MUST ensure thatthe Hop-by-Hop Identifier field contains the same value that was found in thecorresponding request. The Hop-by-Hop identifier is normally a monotoni-cally increasing number, whose start value was randomly generated. An an-swer message that is received with an unknown Hop-by-Hop Identifier MUSTbe discarded. [RFC3588]

End-to-End ID [...]is used to detect duplicate messages. [...] Senders of requestmessages MUST insert a unique identifier on each message. The identi-fier MUST remain locally unique for a period of at least 4 minutes, evenacross reboots. The originator of an Answer message MUST ensure that theEnd-to-End Identifier field contains the same value that was found in thecorresponding request. The End-to-End Identifier MUST NOT be modifiedby Diameter agents of any kind. The combination of the Origin-Host andthis field is used to detect duplicates. Duplicate requests SHOULD cause thesame answer to be transmitted (modulo the hop-by-hop Identifier field and

37

Chapter 3 Infrastructure Design and Requirements

any routing AVPs that may be present), and MUST NOT affect any statethat was set when the original request was processed. [RFC3588]

AVP code The AVP Code field uniquely identifies an attribute (in combinationwith the Vendor-Id field). Diameter AVP codes are also allocated and man-aged by IANA.

AVP Flags The AVP Flags field informs the receiver how each attribute mustbe handled. Allowed values are ”P” (encryption for end-to-end security),”M”(andatory), ”V”(endor-Specific)

AVP Length The AVP Length field carries the number of octets in this AVPincluding AVP Code, AVP Length, AVP Flags, Vendor-ID field and AVPdata.

Vendor-ID The Vendor-ID field can be present if the ”V” flag bit has been set.It holds a IANA assigned Vendor-ID.

The first version of the BSF was based on a C++ implementation of the Diam-eter protocol stack. To use the C++ libraries of this implementation within aJava BSF implementation, several Java classes were necessary. The usage of thisC++/Java mixture caused problems in terms of stability and reliability. One ofthe main requirements therefore is to develop a stable pure Java based Diametercommunication. This includes the usage of a Java Diameter stack for Diameterconnectivity between NAF, BSF, and HSS. The Java Diameter stack used for thisthesis’s BSF and NAF implementation has been written at Fraunhofer FOKUS byDragos Vingarzan. More details on the stack can be found in the implementationchapter in section 4.2.3.

3.3 Standard GBA With Mobile Equipment

This section describes the GBA ME case as specified by 3GPP/3GPP2. The rel-evant specifications have already been discussed in section 2.6. However, whereappropriate, the corresponding specification will be named again for the conve-nience of the reader.

38

3.3 Standard GBA With Mobile Equipment

3.3.1 The Bootstrapping Procedure

The bootstrapping of key material occurs between UE - BSF - HSS within theoverall GBA architecture as shown by figure 3.2. The sequence chart 3.3 shows

Ub

Ua

Zh

Zn

HSS

AS

UE

BSF

NAF

Figure 3.2: The Bootstrapping Procedure

the message exchange.

UE BSF HSS

1. GET (IMPI)

4. 401, Nonce

6. GET (IMPI, RES)

2. MAR

3. MAA

8. 200 OK

7. Authentication and generation of key material

5. Generation of response and session keys

9. Generation of key material

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

1. GET (IMPI) This initial request starts the bootstrapping procedure. The UEsends the HTTP GET request to the BSF. This request must contain the

39

Chapter 3 Infrastructure Design and Requirements

user’s private user identity, the IMPI. An example request is given in thelisting below:

GET / HTTP/1.1Host: bsf .open−ims.org:8080User−Agent: Bootstrapping Client Agent; Release−6Date: Mon, 01 Jan 2007 00:00:01 GMTAccept: ∗/∗Referer: http://naf.open−ims.orgAuthorization: Digest username=”veryCrypticIdentifier@bsf .open−ims.org”, realm

=”bsf.open−ims.org”, nonce=””, uri=”/”, response=””

The most important part of this request is the Authorization header whichcarries the private user identity (veryCrypticIdentifier@bsf.open-ims.org).This is a cryptic identifier which is usually not known to the user. It isstored in the UICC/ISIM. The realm parameter carries the name of thenetwork where the IMPI is authenticated and the uri parameter carries thesame value as the request URI.It is assumed here that ”a new UICC card was just inserted into the terminal,and there is no other cached information to send. Therefore, ”nonce” and”response” parameters (directives) are empty.” [TS24.109]

2. MAR Step two and three are executed over interface Zh between BSF and HSS.This is Diameter communication. The BSF requests Authentication Vectors(AV) and GBA User Security Settings (GUSS) from the HSS, correspondingto the IMPI obtained from step one by sending a Multimedia-Auth-Request(MAR). For a detailed listing of the MAR and MAA commands please referto appendix B. As specified in [RFC3588], Diameter makes use of AttributeValue Pairs (AVP). The User-Name AVP carries the IMPI and allows the HSSto fetch the correct AV and GUSS for the user requesting the bootstrappingprocedure.

3. MAA The Multimedia-Auth-Anwser (MAA) is returned from the HSS provid-ing the BSF with: The AVs (carried inside the SIP-Auth-Data-Item AVP)and the GUSS (carried inside the GBA-UserSecSettings AVP) for the IMPIobtained from step one. The AV has the following format:

AV = RAND‖AUTN‖XRES‖CK‖IK

RAND: this is a random number used to generate the XRES, CK, IK, and

40

3.3 Standard GBA With Mobile Equipment

part of the AUTN.

AUTN: this value is called Authentication token and is a 128 bit valuegenerated by the HSS.

XRES: this is the expected result from the UE. The BSF compares thedigest value of RES (send by the UE in step six) with the digest valueof XRES. If they are identical, the UE is expected to know the corre-sponding secret.

CK: this value is called Cipher Key and is part of the key material whichthe UE will create in step nine. BSF and UE will then dispose of thesame key material.

IK: this is the Integrity Key, which is also part of the key material.

4. 401, Nonce The BSF stores the AV and GUSS for the corresponding IMPI.In case that the HSS sends more than one AV, the BSF needs to select anAV for further proceedings.The BSF challenges the UE with a HTTP 401 Unauthorized response car-rying RAND and AUTN within the nonce field (according to [RFC3310]).This is send to the UE in order to demand authentication. The nonce willbe something like:CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==.

HTTP/1.1 401 UnauthorizedServer: bsf .open−ims.orgDate: Mon, 01 Jan 2007 00:00:02 GMTWWW−Authenticate: Digest realm=”bsf.open−ims.org”, nonce= base64(RAND +

AUTN + server specific data), algorithm=AKAv1−MD5, qop=”auth−int”

The important header here is the WWW-Authenticate header. The nonce

includes a base64-encoded value of the concatenation of: RAND, AUTN andserver specific data. The algorithm field instructs the ME which algorithmto employ. The field qop stand for quality of protection and is set by defaultto auth-int. This means that the payload of this message and the responseshould be integrity protected.

5. Generation of response and session keys Upon the reception of the HTTP

401 Unauthorized message from the BSF, the UE extracts the RAND and

41

Chapter 3 Infrastructure Design and Requirements

AUTN values from the nonce value for further processing. The implemen-tation uses the HTTP Digest AKA [RFC3310] utility classes for the 3GPPMilenage alghoritm [TS35.205] which have been implemented by SebastianLinkiewicz for the use of the FOKUS research community. The UE employsDigest AKA and 3GPP Milenage for calculation of the authentication chal-lenge response RES (using different parameters as defined in [RFC3310]).The UE furthermore computes the keys IK and CK.

6. GET (IMPI, RES) After successful generation, a digest of the authenticationchallenge response RES is send to the BSF together with the IMPI (this hasobviously to be the same value as in step one) in a HTTP GET.

GET / HTTP/1.1Host: bsf .open−ims.org:8080User−Agent: Bootstrapping Client Agent; Release−6Date: Mon, 01 Jan 2007 00:00:03 GMTAccept: ∗/∗Referer: http://naf.open−ims.orgAuthorization: Digest username=”veryCrypticIdentifier@bsf .open−ims.org”, realm

=”bsf.open−ims.org”, nonce=base64(RAND + AUTN + server specific data),uri=”/”, qop=auth−int, nc=00000001, cnonce=”7865kjh96853h98645234975642g8jd2”, response=”7865kjh96853h98645234975642g8jd2”, opaque=”7fff765d453hkkt6d3419j9854g47d34”, algorithm=AKAv1−MD5

The Authorization header carries the response to the authentication chal-lenge received from step 4 in the response field. The other values are:

username: The users IMPI.

realm: Name of the network where the IMPI is authenticated.

nonce: The nonce value that was received from the BSF.

uri: The same value as the request URI.

qop: Quality of protection, by default auth-int if no other security mech-anisms like TLS are employed.

nc: Needs to be set only if qop has been set. Stands for nounce-count andis the enumeration of requests (including the current request) with a

42

3.3 Standard GBA With Mobile Equipment

nonce.

cnonce: Needs to be set only, if qop has been set. Is a quoted-string, whichis offered by the client in order to enable mutual authentication. It isfurthermore used by both client and server to avoid chosen plaintextattacks and to provide some message integrity protection. Please referto [RFC2617] for a more detailed description.

response: Is send to prove knowledge of the shared secret between UEand HSS. Is compared to the XRES digest at the BSF. Both need tobe identical for successful authentication.

opaque: Data string specified by the server which should be returned un-changed by the client.

algorithm: The algorithm employed.

7. Authentication and generation of key material The BSF compares the di-gest values of the authentication response RES with the expected response,XRES. The user has successfully been authenticated if the two values match.The private user identity (IMPI) is registered in the BSF and a Bootstrap-ping transaction Identifier (B-TID) is generated for this IMPI. The BSFfurthermore stores B-TID, IMPI, CK, and IK. Later, the NAF specific keymaterial is generated from the stored tupel.

8. 200 OK If the RES and XRES digest match, the BSF sends a HTTP 200 OK

response to the UE. In case of failure the HTTP 401 Unauthorized messagefrom step four is re-send.

HTTP/1.1 200 OKServer: bsf .open−ims.orgAuthentication−Info: qop=auth−int, rspauth=”7865

kjh96853h98645234975642g8jd2”, cnonce=”7865kjh96853h98645234975642g8jd2”, nc=00000001

Date: Mon, 01 Jan 2007 00:00:04 GMTExpires: Mon, 01 Jan 2007 01:00:04 GMTContent−Type: application/vnd.3gpp.bsf+xmlContent−Length: (...)

<?xml version=”1.0” encoding=”UTF−8”?><BootstrappingInfo xmlns=”uri:3gpp−gba”

<btid>8I2oC9QuNfsDRA0f8m9iXwAAAAABigAAyqP6q2U4L04=@bsf.open−ims

43

Chapter 3 Infrastructure Design and Requirements

.org</btid><lifetime>3600</lifetime>

</BootstrappingInfo>

The Authentication-Info header carries the server authentication infor-mation. Note that this header can include the rspauth parameter, which isthe response digest. The server thereby proves to the ME that it also knowsthe user’s secret (response authentication). For more details, please referto [RFC2617]. The Expires field carries the date and time after which theresponse is expired. The body of this message carries some bootstrappinginformation including the users B-TID. This can be used for anonymity atdifferent NAFs if used as a pseudonym identifier. The NAF can retrieveGUSS for the user with this B-TID at the user’s home-BSF. More on thisin the following sections.

9. Generation of key material The UE generates the key material Ks by con-catenating CK and IK. Depending on whether GBA ME or GBA U is em-ployed, either the ME stores the B-TID and Ks or the UICC stores thistuple. The NAF specific key material Ks NAF is generated on the Ua in-terface which will be discussed in detail in the next section.

3.3.2 Usage of the Bootstrapped Security Association onUE-NAF Communication

Once the UE has obtained valid key material over reference point Ub, it canstart communication with the NAF. The NAF obtains NAF specific key materialKs NAF from the BSF. The BSF generates this from the key material Ks. TheNAF specific key material is used to authenticate and optionally secure the com-munication channel between the NAF and the UE. The sequence chart 3.5 showsthe message exchange for HTTP Digest Authentication with the bootstrappedsecurity association at the NAF. The HTTP(S) client application resides in theME. B-TID is uses as a username while Ks NAF is used as the correspondingpassword for HTTP Digest. In this mode, communication can take place inside aTLS [RFC2246] tunnel. This implicates that the TLS session must be establishedprior to step 1.

0. (optional) TLS tunnel establishment The TLS tunnel can either be estab-lished with shared key-based UE authentication and certificate-based NAFauthentication or shared key-based mutual authentication between UE and

44

3.3 Standard GBA With Mobile Equipment

Ub

Ua

Zh

Zn

HSS

AS

UE

BSF

NAF

Figure 3.4: Accessing the AS via the NAF

NAF. The implementation currently supports server-authenticated TLS wherethe client has been equipped with the server certificate or trusts all NAFservers. This can be configured in the client. Client authentication isachieved by applying HTTP Digest as follows.

1. GET The client sends this initial HTTP GET to access a service. It includesa User-Agent header carrying the static string 3gpp-gba. This indicatesto the NAF the 3GPP-bootstrapping-based authentication is supported bythis client.

2. 401 Unauthorized If the the string 3gpp-gba is included in the User-Agent

header within the request from step 1, the NAF can authenticate the UEbased upon a bootstrapped security association.The NAF responds with with a HTTP 401 Unauthorized carrying a WWW-Au

thenticate header. This header contains a challenge and instructs theUE to use HTTP Digest Authentication with a bootstrapped security as-sociation. The algorithm used for this thesis’s implementation is the MD5algorithm. The NAF can set the quality of protection attribute to auth,if communication is taking place inside a server-authenticated TLS tunnel.This means that the payload of the following HTTP requests and responsesis not protected by HTTP Digest, but by the TLS layer.

3. Generation of NAF specific key material The UE makes use of the key deriva-tion function (KDF) as specified in [TS33.220] in order to create the NAFspecific key material. This is done in both GBA ME and GBA U. In caseof GBA U, the two keys Ks ext NAF and Ks int NAF are generated, pleaserefer to Appendix C for the definition of the key derivation process.

45

Chapter 3 Infrastructure Design and Requirements

UE BSFNAF

1. GET

2. 401 Unauthorized

4. GET (B-TID, response)5. BIR (B-TID)

6. BIA (Ks_NAF, GUSS)

8. 200 OK

3. Generation of NAF specific key material

7. Authentication

9. Authentication

0. TLS tunnel (optional)

Figure 3.5: HTTP Digest Authentication With Bootstrapped Security Association[TS24.109], modified

If the UE does not have a bootstrapped security association available (thatmeans that the bootstrapping procedure over reference point Ub has not yettaken place), it must obtain this association by execution of the Ub interfaceprocedures as outlined in section 3.3.1.

4. GET (B-TID, response) After generation of the NAF specific key material,the UE is now able to generate a HTTP request carrying an appropriateAuthorization header as response to the authentication challenge receivedin step 2. The B-TID serves as the username and the NAF specific key mate-rial Ks (ext) NAF as the password for the digest calculation (the parameterresponse as specified by [RFC2617]). The request contains furthermore theattributes realm, nonce, uri, qop, nc, cnonce, opaque, and algorithm.The attributes have already been explained in section 3.3.1, note that inthis case the algorithm is MD5.

5. BIR (B-TID) The NAF sends a Bootstrapping-Info-Request message (Diam-eter) to the BSF in order to obtain the NAF specific key material (Ks NAFor Ks ext NAF in case in GBA ME, Ks int NAF in case of GBA U (theHTTPS client resides in the UICC)) as well as the GUSS for that user. Theuser is identified by the B-TID. Note that the IMPI cannot be calculated inany way from the B-TID. The B-TID might therefore serve as an anonymous

46

3.3 Standard GBA With Mobile Equipment

identifier for NAFs that are not intended to obtain the user’s IMPI.The NAF can restrict the access to services to UICC-based applications de-pending on the local configuration. In this case, only Ks int NAF as key isaccepted.The Diameter messages exchanged in step 5 and 6 are specified by [TS29.109]and are also given in detail in Appendix B.

6. BIA (Ks NAF, GUSS) The BSF responds to the BIR with a Bootstrapping-Info-Answer. This provides the NAF - for that user - with: NAF specifickey material for UE authentication (Step 7), GUSS, and IMPI (optional).The values are stored at the NAF for further use on interface Ua.

7. Authentication The NAF inspects the Authorization header included withthe user request from step 4. The NAF uses the B-TID and the NAFspecific key material obtained from the BSF for the corresponding digestvalue calculation. The NAF also compares the DNS name in the realmattribute to its own. The calculated values are compared with the receivedvalues in the Authorization header. If the values match, the NAF assumesthe user to be successfully authenticated.

8. 200 OK This HTTP 200 OK response is send to the UE in order to indicatesuccessful authentication.

9. Authentication The UE also verifies the server-generated message by inspect-ing the Authentication-Info header. In the successful case, the UE acceptsthe server-payload.

This section with its two subsections has outlined how to obtain the key materialused to secure reference point Ua. The involved IMS components are BSF, NAFand HSS. This scenario furthermore assumed the user to use a GBA-enabled deviceequipped with a UICC/ISIM. The device runs the protocols with BSF and NAFand is able to handle the GBA-specific protocol conventions such as special HTTPheaders, AKA support, etc. Such GBA-enabled client devices/applications are notyet commercially available. Therefore, a GBA demonstration client applicationhas been implemented to demonstrate the GBA procedures.However, this thesis aims at enabling the GBA for many currently used devices.This is why the next section introduces a modified GBA infrastructure setup. TheUE shall now no longer dispose of a UICC/ISIM. This is true for home PCs, publicterminals or any other device with IMS connectivity but without UICC/ISIM.These devices must also be able to access IMS HTTP ASs, so please proceed tothe next section for a description of this extended design scenario.

47

Chapter 3 Infrastructure Design and Requirements

3.4 Fixed Line GBA Access Without UICC/ISIM

This section proposes a secure way of running the GBA procedures from a termi-nal without UICC/ISIM. This especially aims at users that want to access HTTPservices offered by IMS Application servers from fixed line terminals. This requiressome modifications to the GBA infrastructure as it is currently specified by 3GPPand 3GPP2. Figure 3.6 shows one of the major modifications that have beenimplemented. In addition to BSF and NAF, this involves an Authentication page

Ub Zh

Zn

HSS

AS

UE

BSF

NAF

HTTP2IMS GW

Ua*

Ub*

Figure 3.6: Fixed Line GBA Access Without UICC/ISIM With the HTTP to IMS Gate-way

or HTTP2IMS GW residing on a network component which has two interfaces.On the UE side (Ub*) this is a standard web page listening for HTTP request.On the BSF side, the web component is prepared to run the Ub reference pointprotocols with the BSF. Note that interface Ub* is not standardized in any way.This approach can best be understood realizing that all client Ub functionalityhas been moved to the web component (HTTP2IMS GW) that is interacting withthe BSF on the client’s behalf. This includes the user’s IMPI, shared secret withHSS and AKA support. The client only needs to run standard HTTP with theHTTP2IMS GW on interface Ub* while the actual GBA functionality is run be-tween the HTTP2IMS GW and the BSF on interface Ub.The HTTP2IMS GW shall display a login page to the user. The login usernameand password can be set by the user. The password must contain a minimum of10 characters including at least one normal and one capitalized letter, a number,and one special character in order to assure a certain level of protection againstbrute-force (see Glossary) and dictionary attacks (see Glossary). Additionally,the login page shall increasingly delay communication every time a key is falselyentered. This makes the success of brute-force or dictionary attacks unlikely.

48

3.5 The NAF Authentication Proxy

The login credentials shall be mapped to the user’s ISIM security parameters(IMPI and shared secret with HSS). This shall enable the HTTP2IMS GW to runthe entire Ub protocol with he BSF as described in the previous section. Aftera successful Ub procedure run, the HTTP2IMS GW writes a cookie with B-TID,UID (more on this in section 4.1.2) and Ks NAF to the user’s browser. The cookiewill be read and analyzed by the NAF via interface Ua*. The gateway furthermoreredirects the user’s browser to the NAF and attaches a user-selected UID to theURL. This enables the NAF to obtain the desired UID and to continue with theUa* interface procedures.On interface Ua* the NAF shall be able to recognize the UE and that a suc-cessful bootstrapping event has already occurred with the HTTP2IMS GW. TheNAF shall therefore allow communication with the connected ASs acting as anauthentication proxy and reverse proxy providing Single Sign-On service access.

This roughly described how the HTTP2IMS GW works and defined some require-ments that need to be met to ensure a certain level of security. More on theHTTP2IMS GW can be found in the implementation chapter. The next sectiondescribes the NAF and its behavior as an authentication proxy.

3.5 The NAF Authentication Proxy

The idea of the NAF acting as an authentication proxy is to relieve the connectedASs from security (authentication and channel security) tasks. The NAF operatesin this mode as a reverse proxy.”A reverse proxy is a web server system that is capable of serving web pages sourcedfrom other web servers (AS), making these pages look like they originated at thereverse proxy. [TS33.222] In addition, [RFC3040] clarifies the reverse proxy oper-ation mode.This means that requests targeting any AS go through the NAF. From now on, theNAF will be called AP (Authentication Proxy) if the AP functionality is intendedto be expressed. The AP terminates the TLS tunnel between UE and AP whichis shown by the tube between UE and NAF / AP in figure 3.7. The ASs (in figure3.7 this is service 1-3 and AS) are not publicly accessible. Their host names are re-solved to the IP address of the AP. This is true for all ASs that are intended to beaccessible vie the AP. The concept of accessing a host (the AP) via different DNSnames, is called virtual host concept. The following example might clarify this:The user enters the URL of service 1 in the address field of his browser. This mightbe something like http://as.open-ims.org/service1/service.jsp. Due toDNS configuration this is resolved to the public IP address of the AP. The AP

49

Chapter 3 Infrastructure Design and Requirements

ASUE NAF / AP

Ua /Ua*

Service 1

Service 2Service3

Zn

BSFUb

Figure 3.7: The Authentication Proxy

can now authenticate the user, can display some welcome page, can initiate a TLSsession, or can display a page that has been retrieved from the actual AS (reverseproxy behavior). At this point many different configurations are possible. TheAP configuration of this thesis’s implementation is discussed in section 4.3.2. TheAP may replace the Ut interface between client and AS. This is shown in figure3.10 and discussed in section 4.3.2.Sequence chart 3.8 is given below in order to define the AP behavior requirementsand clarify the interactions with the BSF and the ASs. Please note that it isassumed for this scenario that a non-GBA-enabled terminal without ISIM is used,although the AP mode also works with a GBA-enabled terminal with UICC/ISIM.As this requires the terminal to implement the reference point Ua and Ub protocollogic, this draws restrictions on the client device to be used.

1. GET The user enters the URL of a service in the address field of his browser.For example: https://as.open-ims.org/service1/service.jsp. Due toDNS configuration this is resolved to the public IP address of the AP and therequest is directed to the web component /service1/service.jsp. The APweb server can be configured to direct all requests to the AP’s authenticationservlet, which checks for cookies that have been set in the realm of the APand any URL parameters.

2a. Redirect All client requests that do not target the TLS port of the AP areredirected to the TLS port with the url scheme ”https”. A TLS session isnow established between the AP and the client (server authenticated TLSsession). The AP sends a certificate to the client which need to be accepted

50

3.5 The NAF Authentication Proxy

by the user in order to proceed. The certificate should have been issued bya widely trusted certification authority. Up to date browsers come with the

Bootstrapping Procedure

UE BSF HSS

1. GET

4. credentials

3. Login page

5. Ub logic

APHTTP2IMS GW AS

6. Zh logic

8. Cookie(B-TID, UID, MD5(Ks_NAF))

10. Zn logic

12. GET (X-3GPP-asserted-ID)

13. Content14. Content

15. GET 16. GET (X-3GPP-asserted-ID)

17. Content18. Content

11. B-TID, GUSS, Ks_NAF

2a. Redirect

7. B-TID, UID, Ks

9. Redirect

TLS Tunnel

2b. Redirect

TLS Tunnel

Figure 3.8: Service Access via HTTP2IMS GW and AP Without GBA-Enabled Device

root certificates of a wide range of trusted authorities. If the AP presentedcertificate has been issues by one of the trusted certification authorities, theuser’s browser can validate the certificate to be trusted. In any other casethe user needs to accept the certificate presented by the AP in order toproceed.

2b. Redirect The client is redirected to the HTTP2IMS GW if the User-Agent

51

Chapter 3 Infrastructure Design and Requirements

HTTP header in the request does not contain one of the static strings”3gpp-gba” or ”3gpp-gba-uicc”. If the string is not present, this indicatesa non-GBA-capable client to the NAF, which therefore redirects to theHTTP2IMS GW. A TLS session is established between the client browserand the HTTP2IMS GW.

3. Login page The HTTP2IMS GW displays a login page.

4. Credentials The user provides credentials, that is a username and a password.Note that as outlined above, the credentials must meet some requirementsin terms of password length and use of special characters.

5. Ub logic This step involves the Ub communication as already explained insection 3.3.1. The HTTP2IMS GW has the user’s IMPI and the long termsecret (shared secret with HSS), which has been provisioned with the user’sinitial subscription for the HTTP2IMS GW service.

6. Zh logic The BSF runs the Zh specific protocol procedures which is Diametercommunication with the HSS in order to obtain Authentication Vectors. Asthis has also been discussed in section 3.3.1, please refer to this section andAppendix B for further details in these steps. Step 5 and 6 represent theBootstrapping Procedure.

7. B-TID, UID, Ks After the execution of the Bootstrapping Procedure, theHTTP2IMS GW disposes of a B-TID, a preferred UID (selected by theuser or default UID), and the Ks. The key material Ks serves for calculationof the NAF specific key material Ks NAF.

8. Cookie(B-TID, UID, Ks NAF) The HTTP2IMS GW writes four cookies tothe user’s browser containing the B-TID, the user preferred UID, the NAFspecific key material Ks NAF, and the lifetime of the cookies. The liftetimeof the cookies is the lifetime of the key material. If this is expired, the AP willnot accept further requests and redirect the client back to the HTTP2IMSGW for key renewal.

9. Redirect The HTTP2IMS GW redirects the user’s browser back to the TLSsecured AP and adds the UID to the URL. The AP shall read and analyzethe URL parameters and cookies. The cookies can only be read, if theHTTP2IMS GW resides within the domain of the AP. This will be discussedin more depth in section 4.1.3.The AP should now have received the security parameters that have beenobtained via Ub. The AP can now proceed to check these values against the

52

3.5 The NAF Authentication Proxy

expected values. This is done throughout the next steps.

10. Zn logic Over reference point Zn, the AP receives the key material belongingto the B-TID that has been received in step 9. The AP furthermore receivesthe GUSS and optionally (depending on the BSF’s policy) the user’s IMPI.Please refer to section 3.3.2 and Appendix B for further details on Zh com-munication.

11. B-TID, GUSS, Ks NAF The AP disposes of the B-TID, the GUSS, theKs NAF and checks the values read from the client cookie against the val-ues received from the BSF. If the values match and are not yet expired(key/cookie lifetime), the client is allowed to access the services.

12. GET(X-3GPP-asserted-ID) Upon all subsequent client requests, the APverifies that the client disposes of a valid cookie. If so, the AP adds theX-3GPP-asserted-ID header to the HTTP request and forwards this to theAS. The X-3GPP-asserted-ID is the preferred UID (=IMPU) that is savedin the cookie and has also been transfered to the AP in the URL from step9. The AS extracts the X-3GPP-asserted-ID and offers services based onthis identity.

13. Content Content refers to the actual service content. Usually, this is somekind of webpage that is displayed to the user. This might offer the userthe possibility to download content, display certain information, allow themanagement of online resources and so on.

14. Content The AP forwards the service page to the client.

15. GET On all subsequent requests the client must present the cookie to the APin order to be allowed to access the services. The cookie shall contain B-TID, Ks NAF, and the UID. The B-TID serves as a username and Ks NAFserves as the corresponding password. The UID (=IMPU) is the user identityknown by the AS.

16. GET(X-3GPP-asserted-ID) The AP adds the user identity to all requeststo allow the ASs to offer services based on this user identity.

17. Content The service content.

18. Content The service content.

53

Chapter 3 Infrastructure Design and Requirements

3.6 Interface Ut Replacement and the OMAAggregation Proxy Interface XDM-3

The reference point Ut is defined for UE - AS interconnection. As shown in fig-ure 3.9, it resides between the UE and the Application Server. The purpose of

UE S-CSCF

HSS

ApplicationServer

Ut

Cx

Sh

ISC

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

the Ut interface is enabling the user to manage service information. Such servicerelated information includes creation and assignment of Public Service Identities,management of authorization policies, etc.As specified in [TS23.002], for the Ut reference point, the HTTP protocol shall besupported.However, [TS33.222] specifies a Ut interface ”replacement” as shown in figure 3.10.The Authentication Proxy (AP) resides between the client and the AS. In the fol-

UE

NAF (AP)

Presence

Messaging

Conferencing

New services

Ut

Ua

Zb/Za

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

lowing the connection between the 3GPP specified interface Ut, the GBA andespecially the NAF as authentication proxy, and the OMA specified architectureof XML Document Management enablers is described.

54

3.6 Interface Ut Replacement and the OMA Aggregation Proxy Interface XDM-3

”The XML Document Management defines a common mechanism that makesuser-specific service-related information accessible to the service enablers that needthem. Such information is expected to be stored in the network where it can belocated, accessed and manipulated (created, changed, deleted, etc.). XDM specifieshow such information will be defined in well-structured XML documents, as well asthe common protocol for access and manipulation of such XML documents: XMLConfiguration Access Protocol (XCAP)” [OMAxdm]The documents that are accessed and changed via XCAP are stored in a XMLDocument Management Server (XDMS).Access to the documents need to be secured and XDM clients must be authenti-cated before accessing any XDM services. XML Document Management Clients(XDMC) are entities that provide access to the various XDMS features. They canbe implemented in both terminal and server entities. To access XML documentson a XDMS, usually, a XDMC is implemented in the UE, which contacts a so-called Aggregation Proxy, which is the contact point for all XDM Clients.Figure 3.11 gives an overview of the entire XDM architecture. The OMA Ag-

XD

M C

lient

Sha

red

XD

MS

SIP

/ IP

Cor

e

Aggregation Proxy

Enabler specific XDMS

Enabler specific Server

XDM-1

XDM-3

XDM-2

XDM-4

Figure 3.11: XML Document Management Architecture [OMAxdm]

gregation Proxy (among other features) authenticates XDMCs and routes XCAPrequests to the correct XDMS. The interface between XDMC and AggregationProxy is the XDM-3 reference point. The protocol for this interface is XCAPwhich is carried over HTTP. Via XDM-3 mutual authentication occurs betweenXDMC and Aggregation Proxy. The UE can manipulate XML documents (create,modify, retrieve, delete) after successful authentication.

But how is all this related to the Ut interface and the GBA?

55

Chapter 3 Infrastructure Design and Requirements

The answer is given by [OMAxdm]: ”When the SIP/IP Core network correspondswith 3GPP/3GPP2 IMS, then the XDM-3 reference point conforms to the Ut ref-erence point [3GPP TS 23.002] [3GPP2 X.S0013-000-A].”This means that as the Ut interface is replacing the XDM-3 interface and as theNAF authentication proxy mechanism (UE - AP - AS) is replacing the Ut inter-face, the NAF AP procedures can be run between XDMCs and the AggregationProxy which is seen as a HTTP AS from the NAF AP point of view. This scenariois also part of the validation chapter, where it will be described, how to obtain acontact list (XML contact document) from the FOKUS XDMS via the NAF/APand the Aggregation proxy.However, OMA also includes the possibility, that the Aggregation Proxy acts asan Authentication Proxy (AP) as specified by 3GPP in [TS33.222]. This is de-fined in [OMAap] which specifies the OMA Aggregation Proxy to be a HTTPreverse proxy [RFC3040] that can assert the XDMC identity by inserting theX-XCAP-Asserted-Identity extension header in the HTTP requests after a suc-cessful HTTP Digest Authentication. Note this only occurs cases, where the GAAis not used.Any XDMS residing behind an OMA Aggregation Proxy evaluates the X-XCAP-

Asserted-Identity header provided by the Aggregation Proxy to determine theXDMC identity. If the XDMS is residing behind an OMA Aggregation Proxy anda 3GPP AP (so GBA is used), the identity of the requesting XDMC is obtainedfrom the X-XCAP-Asserted-Identity or the X-3GPP-Asserted-Identity.Like the 3GPP AP, the OMA Aggregation Proxy forwards the requests to thecorresponding XDM Server. It also forwards the response back to the XDMC. Alltraffic is protected by enabling TLS transport security mechanisms.

3.7 The GBA User Security Settings

It has been outlined in detail how authentication can be carried out via the differ-ent interfaces that have been introduced and described by the previous sections.But how can access rules be configured from a network point of view? How canbe achieved that only users with sufficient access rights can use specific types ofservices? Put another way: how can authorization be configured across the dif-ferent GBA components?The GUSS provide a way to do that. While the IMPI and the correspondingsecret are part of any IMS subscription, the GUSS are optional. They can beconfigured in the HSS, the publicly available Fraunhofer Home Subscriber Servercalled FHoSS 1 supports GUSS provisioning. Appendix D lists the XML schema

1http://www.openimscore.org/

56

3.7 The GBA User Security Settings

definition for a GUSS XML document. A graphical representation of a GUSSdocument is given in figure 3.12 to allow a better understanding of how the GUSSare generally structured. Furthermore, listing 3.1 gives an illustrative example to

USS n

USS 2

USS 1

UID n / IMPU nUID 2 / IMPU 2

GBA User Security Settings

0 to n

1 to n

0 to n

IM Private Identitywahle@open-ims.org

ID, Type, [NAF group]1, 1, nafgroup1

Lifetime36000 sec

UID 1 / IMPU1sip:wahle-at-work@open-ims.org

Authorization flag nAuthorization flag 2

Authorization flag 11

Figure 3.12: Graphical Representation of the GUSS

clarify how access rights are encoded in XML using the GUSS.The GUSS are downloaded from the HSS to the BSF where they can be retrievedfrom NAFs upon request (Diameter BIR, see Appendix section B.3). The NAFanalyzes the XML document and can decide, based on authorization flags andUser Security Setttings (USS), if the requested service should be allowed for therequesting entity or not.A typical GUSS XML document contains an attribute ”id” within the element”guss”. This is the user’s IM Private Identity (IMPI) which is first used by theclient on reference point Ub inside the HTTP Authorization header as usernameand is afterward used by the BSF in the User-Name AVP to obtain the AVs andGUSS from the HSS. Every GUSS document contains a lifetime which is a specifickey lifetime with duration in seconds.A GUSS set can contain several USS (User Security Settings). A GUSS set maycontain many USS or none at all (0 to n, compare figure 3.12). The USS areidentified via an attribute ”id” and an attribute ”type” in the GUSS XML ele-ment ”uss”. The USS attribute ”id” is the GAA-Service-Identifier (GSID) which

57

Chapter 3 Infrastructure Design and Requirements

is standardized for 3GPP services to be in a range from 0 to 999999. The cur-rently standardized values for the GSID is the GAA Service Type Code of theparticular service. The GAA Service Type Codes for 3GPP-standardized servicesare defined in Annex B of [TS29.109] and are as follows:

0 Unspecific service1 PKI-Portal2 Authentication Proxy3 Presence4 MBMS

The GUSS also support NAF grouping. With the grouping of NAFs, the operatorhas more flexibility to assign specific NAF servers to specific service types. As theNAF group is optional, if the NAF group is missing, then only the attribute ”id”is used.The GUSS also provide a ”uiccType” choice element which is not depicted byfigure 3.12. This has not been shown for simplifying reasons as the ”uiccType”choice is currently not supported by the implementation. Allowed values for thiselement are ”GBA” (indicates the basic case) and ”GBA U” (indicates that gen-eration of Ks int NAF is also required in the BSF).A GUSS set can contain several USS (or none) and one record of USS can containseveral ”uid” elements (but at least one, compare 1 to n, figure 3.12). The UIDsare the user’s public authentication identities from the HSS. See listing 3.1 for anexample.Furthermore, one record of USS can contain several ”flag” elements (0 to n) whichare authorization flags that indicate which authorization decision should be takenby the NAF. If an authorization flag exists, the NAF has the permission to givethe corresponding service. If a flag is missing, the NAF is not allowed to do so.The flag codes for standardized GAA service types are listed annex C of [TS29.109].The flag codes for the PKI Portal service are:

1 Authentication allowed2 Non-repudiation allowed

The following listing should further clarify the structural design of GUSS XMLdocuments:

Listing 3.1: GUSS Example XML Document

<guss id=”wahle@open−ims.org” xmlns=”guss−schema−of−3gpp−gaa”><bsfInfo>

<lifeTime>3600</lifeTime>

58

3.8 Summary

</bsfInfo><ussList>

<uss id=”1” type=”1” nafGroup=”1”><uids>

<uid>sip:wahle@open−ims.org</uid><uid>sip:wahlediezweite@open−ims.org</uid>

</uids><flags>

<flag>1</flag></flags>

</uss></ussList>

</guss>

The above GAA User Security Settings example for user ”wahle@open-ims.org”defines that PKI-Portal (GAA service type code is 1) services are allowed for theuser’s public identities ”sip:wahle@open-ims.org” and ”sip:wahlediezweite@open-ims.org”. Authentication is allowed (flag 1 exists) but non-repudiation is notallowed (flag 2 is missing) for NAFs that provide the GAA service identified bythe GAA Service Identifier 1, which is the PKI Portal Service.The ”nafGroup” attribute in the element ”uss” is an operator internal groupdesignator for a specific NAF group the USS is valid for. The BSF shall notgenerate UICC-Ks, because a ”uiccType” is missing. A special key lifetime definesthat the duration after which the key expires is 3600 seconds.

This has shown how the GBA implementation shall use the GUSS XML documentsto configure authorization rules for IMS services access. The GUSS are configuredand stored in the HSS from where they are distributed via the BSF to the NAF.The NAF shall then make authorization decisions to grant or deny access tostandardized service types offered via the GBA infrastructure.

3.8 Summary

This chapter gave insights into the structural design of the authentication andauthorization infrastructure introduced by this thesis. The bootstrapping pro-cedure, as the fundamental mechanism to equip the client with a valid securityassociation, has been discussed in detail. Also, how the obtained key material isintended to be used with the NAF/AP should have become clear. Furthermore,the modifications made to enable non-GBA-capable client have been described as

59

Chapter 3 Infrastructure Design and Requirements

well as the NAF acting as an authentication and reverse proxy. Finally, the Utinterface replacement as well as the GUSS, representing the central authorizationconfiguration instrument, have been explained.The next chapter will focus on the realization of the concepts and design decisionsintroduced by this chapter highlighting the software implementation details.

60

Chapter 4

Software Implementation

This chapter will discuss the implementation in detail. The first section identifiesmajor general problems concerning the GBA that will be addressed by the imple-mentation. This thesis’s implementation aims at not just providing a realizationof the corresponding specifications but also solving some problems that are cur-rently not addressed by the standards.Each of the other sections provides a detailed view of the implementation in termsof used technology and realization of the specifications.

4.1 GBA Problems and This Thesis’s Solutions

Instead of merely listing the features of the implementation and thereby providingnothing more than a user manual, this section outlines problems that have beenencountered while working on the implementation of this thesis. The problems aremainly based on specification insufficiencies. Each subsection begins identifyinga problem and, in a second step, then describes the solution provided by theimplementation.

4.1.1 The Need for a UICC/ISIM

As outlined in the previous chapter, TISPAN works on an IMS-centric approachfor both wireless and wireline networks. This access independent IMS is intendedto allow new services to be rapidly developed and deployed. While access indepen-dence is very beneficial for the user, it draws new limitations on authentication.The 3GPP specifications are based on the assumption that the UE is equipped

61

Chapter 4 Software Implementation

with a smart card (UICC) which holds the relevant security values and applica-tions in order to guarantee both network and service authentication (ISIM). Thisassumption does not hold true when is comes to xDSL terminals. As depicted byfigure 2.6 on page 27, on the lowest layer authentication is realized based on Net-work Attachment Subsystem (NASS) credentials. The NASS provides registrationat access level which involves the access authentication run between the UE andthe NASS. While this is very secure on the access level, it is useless on higherlayers as this type of authentication authenticates a piece of hardware rather aspecific user (user identity). A straightforward example might be a family-sharedxDSL line where the access credentials tend to be saved in the DSL modem, whichusually also serves as a router to supply several family home PCs with Internetaccess. In this setup the access level credentials can hardly be used for IMS level orservice level authentication because they identify the DSL modem/router ratherthan the concrete user that is accessing services. Service layer authentication mustbe carried out based on the user identity. This is why it is difficult to reuse theaccess network authentication credentials on higher layers.The field of reusing the authentication/identity information provided by the ac-cess network on the application layer is still subject to research. Interested readerscan refer to [AccAuth] as a starting point for further reading on this topic.In 3GPP IMS the user is identified by a combination of its private identity (IMPI)and its public identity (IMPU). An IMS subscriber has one IMPI but can haveseveral IMPUs that are all mapped to the same IMPI.Please refer to figure 2.6 on page 27 again and note that on the IMS access layer,as well as on the service layer, an ISIM is necessary. The IP Multimedia ServicesIdentity Module (ISIM) is an application that is running on the UICC smart cardin a 3G mobile telephone. It contains parameters for identifying and authenticat-ing the user to the IMS such as the IMPI, one or more IMPUs and the long-termsecret used for authentication purposes and calculation of cipher keys. The prob-lem that arises from the infrastructure shown be figure 2.6 is obvious: how shouldthe UICC, that is usually inserted in a 3G mobile phone, be used on a xDSLterminal (usually a PC)?Three different approaches have been identified as implementation alternatives:

Smart card reader PCs can be equipped with a smart card reader which can readUICC cards. For computers that do not dispose of a smart card reader, thereare USB smart card reader sticks available, as for example shown in figure4.1. By inserting the user’s UICC card into a card reader, applications run-ning on the PC could access the information saved on the card. This wouldenable IMS authentication from a xDSL terminal as the relevant securityparameters can be read from the card and can be used on an applicationrunning IMS authentication with the IMS network. Of course this can berepeated on the service level. Thus, to enable IMS/service layer authen-

62

4.1 GBA Problems and This Thesis’s Solutions

Figure 4.1: USB Smart Card Reader for SIM/UICC cards

tication the terminal need to be equipped with a card reader and certainapplications that are able to extract the relevant information from the cardand use the latter on authentication protocol runs. In 3G network devicesboth functions (card reader + authentication application) are provided bythe mobile device.

Telephone / PC connection Another alternative for equipping the xDSL termi-nal with the ISIM information could be to connect a 3G phone to the PC.This is nowadays a fairly straightforward task thanks to bluetooth technol-ogy. A PC would therefore need to be equipped with a bluetooth wire-less card and an application to extract the relevant security parameters viabluetooth. The phone would also need to be prepared to accept this kindof security data transmission. The main concerns about this approach aresecurity issues. During the last 3 years, bluetooth users faced different kindof bluetooth attacks which enabled the attacker to extract information froma target device without the consens of the victim. Keeping this in mind,the blutooth connection alternative is probably the least favorable one. Ofcourse the connection between telephone and PC can also be established viaa cable, which draws less security concerns, but reduces easy, plug and playuse.

Login page Yet another alternative to enable IMS/service layer authenticationwhile using a xDSL terminal is introduced in the following. This approachhas been realized as part of this thesis implementation. The idea is rathersimple. The UE only needs to be equipped with an up to date web browser.This is why this solutions works for mobile phones as well as fixed line PCs.

63

Chapter 4 Software Implementation

The authentication functionality has been moved to a website presentinga login page to the UE. The user needs to subscribe for this form of au-thentication. During the subscription, the users ISIM security parameters(IMPI and shared secret with HSS) are stored at the HTTP2IMS GW. Thelogin credentials (chosen by the user) are then mapped to the these secu-rity parameters. The user can now log in with its self set credentials atthe HTTP2IMS GW which runs the security protocols with the BSF andassumes the user to be successfully authenticated in case of successful cre-dential match with the HSS.After authentication, the user is able to use all services offered via the GBAinfrastructure from his PC at home, public terminals, or wherever withoutthe need of his UICC/ISIM.Another possibility is to additionally require the user to use its mobile phoneto run the standard GBA procedures with the BSF before providing thecredentials at the login page / HTTP2IMS GW. This would increased theoverall security as two separate logins would be required. This is only pos-sible and useful, if the user disposes of a GBA-enabled mobile device whichcould be used to access the IMS services directly, but the user wants to useits PC because of larger display, keyboard, etc.This HTTP2IMS GW approach solves the problem that a UICC/ISIM isneeded while surfing via PC. The solution will be discussed in greater detailin section 4.2.7.It need to be mentioned however, that this concepts to some extend breaksthe 3GPP security architecture as the UICC/hardware-based security mech-anisms are replaced by a password-based login procedure. The HTTP2IMSGW solution outlined above is threatened by activities such as Phishing andPharming that threaten all web sites and Internet portals. This need to betaken into account when deploying such a solution.

4.1.2 The User Identifier Problem

In digital networks authentication is usually realized by requiring the requestingentity to present credentials along with its request. Credentials are documentsthat prove you are who you claim to be and are generally used to establish arelation of trust between different entities. Within the digital world credentialsoften consist of a username and a password. The username is taken as a useridentifier (the user identity) while the password ensures that the entity presentingthe user identifier is authorized to do so. An example can be found in step 4 offigure 3.5 on page 46. The UE presents credentials to the NAF consisting of theB-TID (the user identity) and a digest response value (the password).

64

4.1 GBA Problems and This Thesis’s Solutions

The problem about the B-TID is that it serves as an identifier for the BSF andNAF to identify a user, but as it was created at the BSF, it has no validity atthe HSS and most ASs. Application Servers use IMPUs to differentiate users andprovide services to them. The limited use of the B-TID however, is also desirableas it can be used as a pseudonym identifier for NAFs that are less trusted thanothers by the BSF. Depending on the local policies at the BSF, a NAF may ormay not allowed to know the user’s IMPI. The BSF can decide not to send theIMPI based on privacy considerations or simply because the NAF does not needit. If the BSF does not forward the IMPI to the NAF the B-TID functions as atemporary user pseudonym.However, a mapping is needed from B-TID to IMPU which can be handled byASs. This is why the GUSS contain elements <uid>. Please refer to Annex Dfor a complete schema of the GUSS and section 3.7 for a detailed description andgraphical representation of the latter. Values of the element <uid> are the user’spublic authentication identities from the HSS. They are used as user identifierson the service layer. Note that as already stated, one or more IMPUs are mappedto one IMPI. While every subscriber has exactly one IMPI, there may be severalIMPUs. A user might therefore have different identities on the service layer (e.g.user-at-home@open-ims.org, user-at-work@open-ims.org, etc.) that belong to thesame subscriber identity (IMPI) that is authenticated on the IMS layer.The user must be able to select a desired identity (UID or IMPU) for the usagewith a specific AS. Based on this identity, the authorization part of the GUSS maycontain indications, which of the applications residing on ASs behind the NAF, auser is allowed to access. However, there is no specified mechanism for this kindof UID selection.The implementation solves this problem by using cookies in case of fixed line accesswith a terminal that does not dipose of an UICC/ISIM. The cookie contains the B-TID, the password, as well as the user selected UID (= IMPU). The UID selectionoccurs at the BSF where the user can choose from a list of UIDs. The UIDs areobtained from the user’s GUSS. The HTTP2IMS GW / BSF writes a cookie to theuser’s browser which can be read by the NAF (more on the problem of commondomain cookies can be found in section 4.1.3). The NAF can forward the desiredidentity (after authentication and authorization checks) to the AS by setting theHTTP header X-3GPP-Asserted-Identity.An alternative to using the X-3GPP-Asserted-Identity might also be to use apseudonym (e.g. B-TID) to be transferred to the AS. This would have to beconfigured on a per AS basis at the NAF. The AS would need to be able to handlepseudonyms and the restrictions resulting from this procedure. The binding of thepseudonym to the user identity would then need to be assured e.g. for chargingpurposes.

65

Chapter 4 Software Implementation

4.1.3 Cross Domain Single Sign-On or the Common DomainCookie Problem

The problem of cross domain SSO is that cookies can usually not be used toachieve cross domain SSO. Cookies provide the only possibility for web servers tosave access information (such as an identifier) in the client. The problem is thatcookies can only be read by the server that set the cookie or other servers residingwithin the same domain of the server that originally set the cookie.This leads to the conclusion that if cookies are to be used to achieve SSO, allservers need to reside within the same domain. This is called the common domaincookie approach. The idea is to to create a common domain for all servers thattrust each other. Such a circle of trust can be described as a set of BSF andNAF/AP operators that have business relationships based on operational agree-ments. For example if bsf.open-ims.org and naf.open-ims.org are both membersof a circle of trust called gba.open-ims.org, then a common DNS domain could beXXX.gba.open-ims.org. As both BSF and NAF reside wihtin the common domain(bsf.gba.open-ims.org and naf.gba.open-ims.org), both are enabled - by use of acommon domain cookie - to discover each others information saved in the cookie.A possible implementation strategy for BSF and NAF/AP operators is describedas follows. Note that this is rather a question of network environment setup (DNSand IP alias) than an implementation issue.NAF / Authentication Proxy server operators should:

• Have previously established a DNS and IP alias for the BSF and the AP inthe common domain.

• Redirect the UE to the AP using the DNS alias and using a ”HTTPS” asthe URL scheme as well as an appropriate port.

The Authentication Proxy additionally implements the virtual host concept. Thismeans that different hostnames are resolved to the AP’s IP address due to DNSconfiguration. This enables the AP to realize cross-domain SSO.An example: the user enters http://as.domain2.de:80/service/sv1.jsp inthe address field of his browser. If this hostname has been configured to beresolved to the AP’s IP address and the AP has been configured as a virtualhost for this hostname, the request hits the AP. The browser has a cookie thathas been set by the BSF for the common domain gba.open-ims.org. The cookieis therefore not send with the request to the AP because the domain name ofthis request is different from gba.open-ims.org. This is why the AP redirects thebrowser to itself. The redirect URL would be https://ap.gba.open-ims.org:

443/service/sv1.jsp. To this request the browser now attaches the common

66

4.1 GBA Problems and This Thesis’s Solutions

domain cookie because the request is targeting a server that is residing within thecommon domain gba.open-ims.org. Note that this occurs although both requests(the original and the redirect) are send to the same IP address (but different hostnames)!With this approach, the AP can serve the client in a cross-domain SSO mannerbased on the common domain cookie.

4.1.4 GBA-Enabled Clients

Currently there are no GBA-enabled client devices and/or GBA-enabled UICCspublicly available. This problem has been approached from two different anglesfor this thesis. On the one hand, the interfaces Ub* (section 4.2.7) and Ua* (sec-tion 4.3.6) and the HTTP2IMS GW (section 4.2.7) have been implemented toenable the GBA usage for standard web browsers that can be used on any devicecapable of running the Mozilla Firefox (version 1.5.0.9) 1 browser or MicrosoftsInternet Explorer (version 6.0)2 or similar browser types. On the other hand, aGBA demonstration client (section 4.4) has been implemented for demonstrat-ing the standard GBA as specified by 3GPP. With these two options, the GBAfunctionalities can be demonstrated and validated. This has been the basis andprecondition for the Open IMS Playground integration of this thesis’s implemen-tation.There is also currently a project underway at FOKUS that aims at developinga GBA browser plugin for the Mozilla based Minimo browser. Minimo is a free,open-source web browser for Windows Mobile 3.

4.1.5 Service Access Configuration Based on User Identities

So far the Fraunhofer FOKUS IMS Playground did manage user identities andaccess rules on the HTTP level in a centralized manner. All connected ASs hadto implement their own access and identity management mechanisms.On the SIP level this is different. A HSS usually provides storage for Initial FilterCriteria (IFC) and Service Trigger Points (STP) for each public identity thatbelongs to a user’s subscription. The Fraunhofer FOKUS Open IMS HSS called

1http://www.mozilla-europe.org/en/2http://www.microsoft.com/windows/ie/default.mspx3Minimo. A small, simple, powerful, innovative web browser for mobile devices. http://www.mozilla.org/projects/minimo/

67

Chapter 4 Software Implementation

FHoSS 4 supports IFC and STP provisioning. IFC and STP data is downloadedto a S-CSCF whenever a user has successfully registered on an IMS network.The IFC and STP data is used by the S-CSCF to trigger particular applicationswhenever a certain set of criteria is met.This thesis’s implementation reuses this paradigm for the HTTP level. The GUSSdata provide the possibility to instruct the NAF to only allow certain servicetypes to certain user identities. The GUSS are downloaded from the HSS to theBSF where they can be retrieved from NAFs upon request (Diameter BIR, seeAppendix section B.3). The NAF analyzes the XML document and can decide,based on the authorization flags, if the requested service should be allowed for therequesting entity or not.This setup enables IMS operators to have a central data store (the HSS) whereboth SIP and HTTP access rules can be configured. On the SIP level, the S-CSCFplays the role of an authentication proxy, on the HTTP layer this is done by theNAF / AP. The FOKUS Open IMS Playground profits from this analogy and thisthesis’s implementation to a great extend as it simplifies user provisioning anddata maintenance.

This section outlined the major problems to be solved by the implementation. Thenext sections give insights into the structure of the implementation and discussthe BSF, the NAF and the demonstration client with all supported interfaces.

4.2 The Bootstrapping Server Function

This section describes the BSF implementation details. The implementation hasbeen realized in Java and is based on several third party Java projects as well asa Fraunhofer FOKUS Java implementation of the Diameter Stack. While the firstversion of the BSF was based on the Opendiameter 5 C++ Implementation ofthe Diameter stack, the currently used Diameter stack version is pure Java whichcontributes to the stability and performance of the entire infrastructure.Figure 4.2 shows the logical components of the BSF implementation. Note thatthe NAF server structure as given by figure 4.8 is very similar to that of the BSFas shown in figure 4.2. More similarities will be outlined throughput the section.The Diameter functionality is provided by two projects called JavaDiameterPeer

and JavaDiameterStackExtension.The HTTP functionality, as the second fundamental part of the server structure,

4http://www.openimscore.org/5http://www.opendiameter.org/

68

4.2 The Bootstrapping Server Function

Diameter HTTP

Zh Zn Ub Ub*

BSF Server

HTTP-to-IMS-Gateway

Figure 4.2: The Logical Structure of the BSF Server

is part of Apaches Jakarta’s embedded Tomcat version bundle 6 7 that has beenintegrated into the BSF. Usually, when tomcat is used as a standalone applica-tion, it has a set of containers that are configured using a server.xml file. In theBSF case, the tomcat functionality has been embedded into the BSF server andtherefore no server.xml file has been used. The instances of the containers arecreated programmatically. The embedded tomcat software bundle includes a JavaHTTP/1.1 connector (tomcat-http.jar) that is used to obtain HTTP functionality.Please refer to table 4.2 for an overview of all third party software libraries suchas the tomcat-http.jar.The reference point Zh and Zn functionality has mainly been realized in two classeswhich are de.fhg.fokus.gaa.bsf.ZhCommandListener and de.fhg.fokus.gaa.bsf.ZnCommandListener. As the interfaces themselves and the messages that are exchangedvia those interfaces play a central role in the entire architecture, they are discussedin more detail in their own subsection 4.2.4 and 4.2.5.The HTTP interface Ub has been realized as a HTTP servlet in the class de.fhg.fokus.gaa.servlet.BSFservlet while the Ub* interface 8 is mainly the class de.fhg.fokus.gaa.servlet.authUserAction. This is part of the Struts framework architecture.Apache Struts 9 is an open-source framework for developing Java EE web applica-tions. It is used to develop application based on a model-view-controller (MVC)architecture and reuses and extends the Java Servlet API. It is a top level Apacheproject since 2005. By using Struts, application logic is separated from the pagesthat are presented to the client. The model (the application logic) is connected to

6http://tomcat.apache.org/7http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/startup/Embedded.html

8Ub* referres to the adapted Ub interface that can be used by normal web-browsers to accessthe infrastructure, while interface Ub usage requires a special Ub-capable client such as aUICC equipped and GBA-enabled smartphone (or the demonstration client introduced insection 4.4)

9http://struts.apache.org/

69

Chapter 4 Software Implementation

Diameter JavaDiameterPeer and JavaDiameterStackExtension projectHTTP embedded tomcat, tomcat-http.jarZh BSFserver project, de.fhg.fokus.gaa.bsf.ZhCommandListenerZn BSFserver project, de.fhg.fokus.gaa.bsf.ZnCommandListenerUb BSFserver project, de.fhg.fokus.gaa.servlet.BSFservletUb* BSFserver project, de.fhg.fokus.gaa.servlet.authUserActionBSF Server BSFserver projectHTTP2IMS GW BSFserver project, webapps IMSserviceTemplate,

de.fhg.fokus.gaa.servlet.authUserAction

Table 4.1: Mapping of Functional Components to Java Projects and Classes of the Im-plementation

the view (JSP pages) via a controller which is commonly known as ActionServlet.A configuration file called struts-config.xml is used to bind together model, viewand controller and thereby create the MVC architecture.The action and action forms can be found in two packages within the main projectssource folder: package de.fhg.fokus.gaa.gui.action and package de.fhg.fokus.gaa.gui.form. The view has been placed in the webapps folder in a folder called pages.Table 4.1 gives an overview of the functional components introduced by figure 4.2.This mapping of the logical components to the concrete Java projects and classesenables the reader to quickly relate the relevant Java sources to their functionwithin the BSF server implementation.As already state above, the BSF server implementation reuses several third partyproject libraries such as XML parser, Logging APIs, a Servlet API, a Struts API,and others. A complete list can be found in table 4.2.

4.2.1 Building and Deployment of the BSF Server

For easy building and deploying of the BSF, the Apache Ant 10 build tool canbe used. Apache Ant is a open source Java-based build tool that facilitates thebuilding by automating the software build processes. It is highly suited to buildJava projects as it has been written in Java itself. Ant uses a XML file (usuallynamed build.xml) to describe the build process and its dependencies. The BSFserver source files also include a build.xml as well as a build.properties file. Thefiles can be adjusted to meet special building requirements. However, there isalso a file named install.txt included which describes the building and installation

10http://ant.apache.org/

70

4.2 The Bootstrapping Server Function

castor-1.0.2.jar Data binding framework for moving data betweenXML documents, Java objects and relational tables.

catalina.jar Implementation of the Catalina servlet containerportion of Tomcat 5

catalina-optional.jar Some optional components of Catalinacommons-beanutils.jar Easy-to-use wrappers around the Java reflection

and introspection APIscommons-digester.jar XML-to-Java-object mapping utilitycommons-el.jar Jakarta commons el, implementing the expression

language used by Jaspercommons-lang.jar Provides extra functionality for classes in java.langcommons-logging.jar Wrapper around a variety of logging API implementationscommons-modeler.jar A model MBeans implementation used by Tomcat to

expose its internal objects through JMXcommons-validator.jar Framework to define validators and validation rules

in an xml filejasper-compiler.jar The JSP 2.0 compilerjasper-compiler-jdt.jar The Eclipse JDT Java compilerjasper-runtime.jar The JSP 2.0 runtimejaxen-full.jar Xpath engine capable of evaluating Xpath expressionsjdom.jar library for accessing, manipulating, and outputting

XML data from Java codejmx.jar Java Management Extensions APIjsp-api.jar The JSP 2.0 APIlog4j.jar Logging APInaming-factory.jar The JNDI implementation used by Tomcat 5 to resolve

references to enterprise resources (EJB, connection pools)naming-resources.jar specialized JNDI naming context implementation used

to represent the static resources of a web applicationsaxpath.jar Simple API for Xpath providing a single point for

Xpath expression parsingservlet-api.jar The Servlet 2.4 APIservlets-default.jar Tomcat’s default servletstruts.jar contains the Java classes distributed by the Struts projecttomcat-coyote.jar Coyote APItomcat-http.jar Standalone Java HTTP/1.1 connectortomcat-util.jar Utility classes required by some Tomcat connectorsxercesImpl.jar Apache Xerces2 XML parser

Table 4.2: Third Party Libraries Used by the BSF Implementation

71

Chapter 4 Software Implementation

process in detail. Please refer to this file for further information of how to buildand install the BSF server.

4.2.2 Configuration of the BSF Server

The BSF is configured via different configuration files. There are mainly threeconfiguration steps toward a working BSF server. The following description givesthe files that need to be adjusted and should covers all necessary configurationissues:

DiameterPeer.xml In order to guarantee diameter connectivity, each diametercommunication endpoint is configured using a XML document named Di-ameterPeer.xml. Target Diameter peers can be configured with this config-uration file but can also be detected and added at runtime dynamically. Afull sample configuration file can be found in Appendix E, please refer tothis location for a description of the configuration file.

bsf.properties The main BSF server configuration is achieved by editing thebsf.properties file. A sample configuration can be found in the Appendixsection E.1. The main configuration settings for the BSF include the BSFhostname, the target NAF location and the target HSS location.

Transport Layer Security The BSF is equipped with a server certificate which isstored in a Java Keystore. The keystore file is named .keystore and should beplaced in a directory named conf in the BSF home directory. The keystorelocation and password should be configured in the bsf.properties file.

BSFuser.xml The registered users for the HTTP2IMS GW service need to beprovisioned with this file. An example file can be found in the Appendixsection E.5. Whenever a new user is registered via the web interface, thefile BSFuser.xml is updated automatically. A new user element is added atthe end of this file. An administrator need to set the according IMPI asregistered with the HSS afterward.

4.2.3 The Diameter Stack

Basic Diameter protocol details have already been outlined in section 3.2. TheJava Diameter Stack used for the BSF implementation has been written at Fraun-

72

4.2 The Bootstrapping Server Function

hofer FOKUS. The stack implementation is based on a socket acceptor that parsesinput and output to known Diameter AVPs. The AVPs are parsed into Java ob-jects. As such they provide the values that are exchanged between the differentDiameter peers to run the application logic.Each communication endpoint is referred to as a Diameter peer. The peers areconfigured using the DiameterPeer.xml. The following code snippet demonstratesthe main configuration settings of a Diameter peer, a full sample configuration filecan be found in the Appendix section E.4:

Listing 4.1: Diameter Peer Configuration

<DiameterPeerFQDN=”bsf.open−ims.org”Realm=”open−ims.org”Vendor Id=”10415”...

>

Please refer to the Appendix section E.4 for more technical details on the JavaDiameter implementation and configuration.

4.2.4 Zh Interface

The Zh interface is a Diameter interface. The Java Diameter stack makes use ofthe listener concept. Therefore, the JavaDiamterPeer project provides a publicinterface called EventListener that is used to implement command listener classes.For the Zh interface the command listener ZhCommandListener has been imple-mented. This listener class is added the BSF Diameter peer upon start up time ofthe BSF Diameter server. Note that the ZnCommandListener for the Zn interfaceis added in the same way:

Listing 4.2: Adding the Listeners at Startup

public void startup (){diameterPeer = new DiameterPeer(”./conf/DiameterPeer.xml”);diameterPeer.addEventListener(new ZnCommandListener(diameterPeer));LOGGER.debug(”Zh Command Listener is active ...”);diameterPeer.addEventListener(new ZhCommandListener(diameterPeer));LOGGER.debug(”Zn Command Listener is active ...”);

73

Chapter 4 Software Implementation

}

Once the listeners have been added, they listen for Diameter messages with thecommand codes associated to the Zh interface. This is only one command code 903(3GPP specified 303, but this collides with the Cx interface command code 303)which is associated to the Multimedia-Auth-Request/Answer message (MAR/-MAA). A detailed description of this command can be found in Appendix B.The Zh message exchange is shown in figure 4.3. Without going into too much de-

HSSBSF

MAR

MAA

Figure 4.3: The Zh Diameter Message Exchange

tails, the most important values exchanged via the Zh interface are: the username(IMPI), the Authentication Vectors (AV), and the GBA User Security Settings(GUSS). The username is send inside the MAR from the BSF to the HSS in theUser-Name-AVP. This AVP is of type UTF8String and carries the users IMPI.The HSS can - based on the user identity (IMPI) - calculate corresponding AVswhich are returned to the BSF inside the MAA in a SIP-Auth-Data-Item-AVP.An AV is then used by the BSF to run the Ub logic with the UE. Along with thisAVs, the HSS may send the GUSS (if present for that user) inside the MAA ina GBA-UserSecSettings-AVP. The XML formated GUSS are read by the BSF,transformed into a Java object using a XML parser, and stored locally for furtherusage with the NAF. The Zh interface procideure results are cached at the BSF.B-TID, GUSS, and AV are hold in hash tables for a corresponding IMPI (a ta-ble for B-TID to IMPI mapping is also provided for interface Zn requests). Thisincreases the response speed of the BSF on the interfaces Ub, Ub*, and Zn. Thevalues are hold for the lifetime of the key material.

4.2.5 Zn Interface

As the Zh interface, the Zn interface is also a Diameter interface. A ZnCom-mandListener has been implemented that listens for Zn messages from the NAFto the BSF. While Zh communcation was BSF-initiated (BSF has client role,HSS is the server), Zn communication is NAF-initiated which makes the BSFa Diameter server. The NAF plays the Diameter client role in the Zn scenario.

74

4.2 The Bootstrapping Server Function

Figure 4.4 shows the Zn message exchange. The NAF sends a Bootstrapping-Info-

BSF

BIR

BIA NAF

Figure 4.4: The Zn Diameter Message Exchange

Request (BIR) to the BSF. The listener at the BSF side notes that a Diametermessage with code 310 has been received and takes this to be a BIR. The BSFruns checks on the received request and tries to populate all needed values into aBootstrapping-Info-Answer (BIA). The message format of the two messages canbe found in Appendix B. The most important values exchanged between BSFand NAF via the Zn interface are the Transaction-Identifier (B-TID) inside theTransaction-Identifier-AVP, the key material inside the ME-Key-Material-AVPor UICC-Key-Material-AVP, and the GUSS inside the GBA-UserSecSettings-AVP.The NAF sends the B-TID to the BSF inside the BIR. The BSF uses the B-TIDto look up the key material and (if present) the GUSS associated with that B-TIDand returns those values to the NAF inside the BIA. For further information onthe interfaces Zh and Zn, please refer to Appendix B or [TS29.109].

4.2.6 Ub Interface

The Ub interface is a HTTP interface. As such, HTTP connectivity must beprovided. This is done by the embedded Apache Tomcat web container that hasbeen integrated in the BSF. The Ub application logic is realized in a HTTP servletthat is deployed on the Tomcat server. The servlet has been implemented in aclass named de.fhg.fokus.gaa.servlet.BSFservlet. The bootstrapping procedure asspecified by 3GPP has already been explained in section 3.3.1. The servlet listensfor an Ub interface conform bootstrapping request as defined by [TS24.109]. Ifit is receiving such a request, it extracts the user identity (IMPI) and calls themethod de.fhg.fokus.gaa.bsf.runZh which runs the Zh Diameter logic with the HSSfor the given IMPI. In the successful case, the HSS returns an AV and - if present- the GUSS for this user. The servlet performs the challenge-response basedAKA mechanism with the client. This is basically a mapping of AKA parametersonto HTTP Digest authentication which enables the usage of AKA as a one-time password generation mechanism for Digest authentication. If authenticationsucceeds, the key material is generated and stored at the BSF. The BSF as wellas the client now dispose of a security association in a form of a bootstrapping

75

Chapter 4 Software Implementation

transaction identifier (B-TID) and key material (Ks) that can be used with theNAF to run and secure Ua interface application logic.

4.2.7 Ub* Interface

As stated before this is a non-specified interface that has been designed and imple-mented to allow non-GBA-capable clients to make use of the GBA infrastructure.The Ub* interface is provided by the HTTP2IMS GW and is a HTTP interface.

a)

b)

Ub

BSFHTTP2IMSGW

Ub*

HTTP2IMSGW+ BSF

Ub*

Figure 4.5: The Ub* Interface

Any client that has an up to date Internet browser installed can make use ofthe Ub* interface. The implementation has been tested with the Mozilla Firefox(version 1.5.0.9) 11 browser and Microsofts Internet Explorer (version 6.0)12. TheHTTP2IMS GW displays a web page that has the Fraunhofer Open IMS Play-gound layout. Existing Cascading Style Sheets (CSS) have been used to give thesite a layout similar to yet existing Playground service pages. Figure 4.6 shows ascreenshot from the HTTP2IMS GW page.

So how can a non-GBA-capable Internet browser access the GBA infrastruc-ture? The user needs to log in at the login page displayed in figure 4.6. The loginusername and password can be set by the user. The password must contain aminimum of 10 characters including a least one normal and one capitalized lettera number and a special character in order to assure a certain level of protectionagainst brute-force and dictionary attacks. Additionally, the login page increas-ingly delays communication every time a key is falsely introduced. If a key isfalsely entered for the same username within the last four minutes, communica-tion is delayed for the current delay plus one second. So for example after 5 falselyentered passwords within the last four minutes, the user has to wait five seconds

11http://www.mozilla-europe.org/en/12http://www.microsoft.com/windows/ie/default.mspx

76

4.2 The Bootstrapping Server Function

Figure 4.6: The HTTP2IMS GW Login Page as a Screenshot

before he can enter a new password. After 8 false passwords, communication is de-layed for 8 seconds and so on. This makes the success of brute-force or dictionaryattacks unlikely as the delay will increase infinitely. The rate of delay increase canalso be increased if deemed appropriate.The gateway contains a mapping from username to IMPI. If the user entered cre-dentials are recognized to be valid (the password matches the expected passwordfor the entered user name) the HTTP2IMS GW obtains AVs and GUSS via theBSF for the IMPI (obtained for the entered username). The AVs and GUSS arestored at the BSF. The HTTP2IMSGW writes two cookies to the browser. Thecookies carry the BTID and the key material for usage with the NAF.As shown in figure 4.5 there are two different setups possible. The first case a)makes use of the Ub interface at the BSF. In this setup it is even possible tohave HTTP2IMS GWs in a domain different from the domain of the BSF. TheUb interface could additionally be secured by IPSec, TLS, or another securitymechanism that would make the Ub connection between HTTP2IMS GW andBSF oven an untrusted network more secure. This however is not necessary as inHTTP Digest AKA, the password is never transmitted over the communicationchannel.The HTTP2IMS GW implementation of this thesis makes use of case b) of figure4.5. BSF and gateway have realized in a single server component. This has theadvantage that there is no need to run Ub logic between the HTTP2IMSGW andthe BSF which leads to increased communication speed.

77

Chapter 4 Software Implementation

The HSS-obtained GUSS contain one or more user identifier (UID). The UID isknown to the ASs and used as the username at the ASs. The user therefore need tohave a choice of which UID to use when accessing an AS. This has been realized atthe HTTP2IMS GW as a list of UIDs (extracted from the GUSS received from theHSS for a certain IMPI). The user sees which UIDs have been registered and areready to be used with different services. Currently all services can be used with allUIDs. An idea for further specification efforts or a proprietary solution might be todistinguish between different services based on the UID. Some services might onlybe accessible with a certain UID, others might be accessible for all selected UIDs,or not be accessible at all. Figure 4.7 shows the UID selection at the HTTP2IMS

Figure 4.7: The UID Selection at the HTTP2IMSGW as a Screenshot

GW. The user that is currently logged in, has two UIDs registered with the HSS:sip:testuserzwei@open-ims.org and sip:testuser@open-ims.org. Beneatheach UID, the available services are listed. In figure 4.7 there are currently three

78

4.2 The Bootstrapping Server Function

different services supported: the O2 Portal, the Smart Messenger service, and acertificate enrollment service (two web browsers are supported, Firefox/Mozillaand Internet Explorer).To sum up, the Ub* approach replaces the 3GPP AKA mechanism between BSFand UE by a simple login procedure. This has clear advantages but also somedrawbacks. The advantage is that the central data and identity store - the HSS -remains the central network component in terms of data storage even when usingGBA with standard Internet browsers. The disadvantage is that the username /password based login procedure is less secure than the AKA mechanism. Anotherdisadvantage is that the HTTP2IMS GW needs to maintain a list of registeredusers. This includes the user’s IMPI which is usually only stored at the HSS.On the other hand, the IMPI is the only value that need to be provisioned atthe HTTP2IMS GW and this could also be automated, which means that when-ever subscribing a new user at the HSS, an IMPI entry could be made in theHTTP2IMS GW user store. This remains an open issue for further research andimplementation efforts.Once the user obtained the cookies carrying the BTID and key material, the cook-ies can be use to authenticate at the NAF. This is the basis of the SSO mechanism.As long a the HTTP2IMS GW written cookie can be read by the NAF (the cookiemust be a common domain cookie, as explained in section 4.1.3), the latter canprovide service access for various applications hosted by one or more applicationservers.

79

Chapter 4 Software Implementation

4.3 The Network Application Function

This section describes the NAF implementation. The implementation, as the BSFimplementation, has been realized in Java and is also based on the FraunhoferFOKUS Java implementation of the Diameter stack. It furthermore relies onseveral third party Java projects that are described by table 4.3, while figure 4.8shows the logical components of the NAF implementation.

Diameter HTTP

Zn Ua Ua*

NAF Server

Authentication Proxy PKI Portal

Figure 4.8: The Logical Structure of the NAF Server

As it was the case with the BSF, the Diameter protocol functionality of the NAF isprovided by two projects called JavaDiameterPeer and JavaDiameterStackExten-sion while the HTTP protocol functionality is part of Apaches Jakarta’s embeddedTomcat version bundle that is also part of the NAF. The reference point Zn func-tionality comes from the class de.fhg.fokus.diameter.zn.ZnCommandListener. TheZn interface is discussed in more detail in subsection 4.3.4.The HTTP interface Ua has been realized as a HTTP servlet in the class de.fhg.fokus.gba.naf.uaservlet.UaServlet while the Ua* interface 13 is mainly the classde.fhg.fokus.gba.naf.servlet.NAFservlet.This was to demonstrate the organizational structure of the NAF server. The

following subsections will discuss the logical components and interfaces in moredetail.

13Ua* referres to the adapted Ua interface that can be used by normal web-browsers to accessthe infrastructure, while interface Ua usage requires a special Ua-capable client such as aUICC equipped and GBA-enabled smartphone (or the demonstration client introduced insection 4.4)

80

4.3 The Network Application Function

castor.jar Data binding framework for moving data betweenXML documents, Java objects and relational tables.

catalina.jar Implementation of the Catalina servlet containerportion of Tomcat 5

catalina-optional.jar Some optional components of Catalinacommons-el.jar Jakarta commons el, implementing the expression

language used by Jaspercommons-logging.jar Wrapper around a variety of logging API implementationscommons-modeler.jar A model MBeans implementation used by Tomcat to

expose its internal objects through JMXjasper-compiler.jar The JSP 2.0 compilerjasper-compiler-jdt.jar The Eclipse JDT Java compilerjasper-runtime.jar The JSP 2.0 runtimejsp-api.jar The JSP 2.0 APIlog4j.jar Logging APInaming-factory.jar The JNDI implementation used by Tomcat 5 to resolve

references to enterprise resources (EJB, connection pools)naming-resources.jar specialized JNDI naming context implementation used

to represent the static resources of a web applicationservlet-api.jar The Servlet 2.4 APIservlets-default.jar Tomcat’s default servlettomcat-coyote.jar Coyote APItomcat-http.jar Standalone Java HTTP/1.1 connectortomcat-util.jar Utility classes required by some Tomcat connectors

Table 4.3: Third Party Libraries Used by the NAF Implementation

Diameter JavaDiameterPeer and JavaDiameterStackExtension projectHTTP embedded tomcat, tomcat-http.jarZn de.fhg.fokus.diameter.zn.ZnCommandListenerUa de.fhg.fokus.gba.naf.uaservlet.UaServletUa* de.fhg.fokus.gba.naf.servlet.NAFservletNAF Server NAFserver projectAuthentication Proxy de.fhg.fokus.gba.naf.servlet.NAFservletPKI Portal de.fhg.fokus.gba.naf.servlet.NAFservlet

and EJBCA external component

Table 4.4: Mapping of Functional Components to the Java Classes and Projects of theImplementation

81

Chapter 4 Software Implementation

4.3.1 Building, Configuration, and Deployment of the NAFServer

As for the BSF, for the NAF a build.xml, as well as a build.properties file is providedthat can be used with the the Apache Ant build tool. The files can be adjusted tomeet special building requirements. There is also a file named install.txt included,which describes the NAF building and NAF installation process in detail. Pleaserefer to this file for further information of how to build and install the NAFserver. The file can be found in the root directory of the NAF server. Thefollowing description introduces the NAF configuration files which need to beadjusted according to the installation environment:

DiameterPeer.xml For diameter connectivity with the BSF, the NAF Diameterpeer need to be configured. The target BSF peer can be configured in theDiameterPeer.xml or can be detected and added at runtime dynamically.A full sample configuration file for the BSF can be found in the Appendixsection E.4. The NAF Diameter peer is configured accordingly.

naf.properties The main NAF server configuration is done via the naf.propertiesfile. A sample configuration file can be found in the Appendix section E.2.The configuration options include the virtual host settings as well as supportof a secure BSF (HTTPS) and support of a non-secure BSF (plain HTTP).

Transport Layer Security The NAF is equipped with a server certificate whichshould be stored in a Java Keystore file. This file should be placed into theconf directory in the NAF root directory. By default, the NAF contains aself-signed server certificate in a default keystore file .keytore. The keystorelocation may be changed by setting a location in the naf.properties files.Also, a keystore password need to be configured in this file.The NAF server certificate is also used by the Authentication Proxy. Thedefault self-signed certificate should be replaced with a certificate from awidely trusted certification authority. Many browsers dispose of a list oftrusted certification authorities and have their root certificates pre-installed.The NAF / AP should be equipped with a certificate signed by one of theseauthorities to avoid warning messages popping up in the user’s browser.Whenever a server presents a non-trusted certificate (a certificate signedfrom a certification authority not existent in the list of trusted authorities),the user is required to accept the certificate before the browser allows furthercommunication. To enable a easy to use and widely trusted infrastructure,the user should not be confronted with warnings like that. Therefore, theNAF / AP should be equipped with a certificate from a trusted authority

82

4.3 The Network Application Function

such as ”VeriSign” 14

4.3.2 The Authentication Proxy

The Authentication Proxy (AP) operation mode is the main operation mode forthe NAF. In this operation mode, the NAF acts as a reverse proxy. While normalproxies connect many clients via the proxy to the Internet, the reverse proxy con-nects many web servers via the proxy to the client/Internet. The 3GPP definitionfor a reverse proxy is: A reverse proxy is a web server system that is capable ofserving web pages sourced from other web servers (AS), making these pages looklike they originated at the reverse proxy. [TS33.222]As shown in figure 3.7 and figure 3.10, the AP may replace the interface Ut thatis defined for HTTP connections between clients and Application Servers (AS).The AP implementation assumes that all connected ASs cannot be reached fromthe client directly. Their hostnames are resolved to the IP address of the AP.Therefore, the AP need to be configured so as to listen for all requests that areintended to be answered by the supported ASs. This is achieved in the implemen-tation by starting the AP with several virtual hostnames, each of them belongingto exactly one AS. So whenever a request, that is intended to hit an AS, is routedto the AP, the AP determines the correct AS (based on the request URL) andforwards the request to the AS. Upon receiving the AS response, it is delivered tothe client.The administrators of the connected ASs need to deploy their applications keep-ing in mind that the AP needs to forward client requests. This means that theremay not be two applications deployed in the same location. The following exam-ple should clearify this issue. Service 1 is deployed at server1.open-ims.org:

8080/presence/service1 while Service 2 is deployed at server2.open-ims.

org:8080/messaging/service2. In this scenario the AP forwards requests forservice 1 to server1.open-ims.org based on the /presence/ part of the URLwhile requests to service 2 are forwarded to server2.open-ims.org because theURL contains a part /messaging/ right behind the port 8080. The AP maintainsa list (defined in naf.properties) of connected ASs and the corresponding URLpatterns (root directories). For the example above this would be:

server1.open-ims.org presence

server2.open-ims.org messaging

Based on the root directory of the applications (presence, messaging) the AP de-

14http://www.verisign.com/

83

Chapter 4 Software Implementation

cides to which AS a request need to be forwarded to. This means that there mustnot be two different applications deployed in the same root directory although be-ing deployed on different server machines. There must be unique root directoriesfor all services across all ASs intended to be supported by the AP. The sampleconfiguration of the NAF including several virtual hostnames is listed in the Ap-pendix section E.2.

4.3.3 The PKI Portal

As specified by [TS33.221] the NAF can function as a PKI portal issuing sub-scriber certificates. This has been adopted for the interface Ua* implementation.Supported browsers are Mozilla-based browsers as well as the Microsoft InternetExplorer. Figure 4.9 gives an overview of the network model for issuing subscribercertificates via the interface Ua*.A Public Key Infrastructure (PKI) can be described as a set of hard- and soft-

Ub*

Ua*

Zh

Zn

HSS

EJBCA

UE

HTTP2IMS GW (BSF)

PKI Portal(NAF)

Figure 4.9: The Modified GBA Infrastructure for PKI Support and Certificate Issuing

ware components including policies, unified processes and servers to administer,verify, and certify user identities. This is done using digital certificates and publickey cryptography (public-private key pairs). PKIs are generally able of issuing,maintaining, and revoking public key certificates and are used to establish a se-cure chain of trust for Internet-based communication. PKIs usually include aCertificate Authority (CA), a Registration Authority (RA), a key directory andmanagement/provisioning tools.A CA issues certificates to, and vouches for the authenticity of entities. Thelevel of trust you can assign to a CA is individual, per CA, and depends on the

84

4.3 The Network Application Function

CAs policy and practices statement. A RootCA has a self-signed certificate and isalso called Trusted Root. Verification of other certificates in the PKI ends with theRootCAs self-signed certificate. Since the RootCAs certificate is self-signed it mustsomehow be configured as a trusted root with all clients in the PKI. [wwwEJBCA]The value of a PKI depends on how trusted the RootCA is. As pointed out before,modern web browsers dispose of a number of pre-installed root certificates fromvarious companies that maintain a RootCA. Theese CAs can mostly be trustedas their business depends on being trustworthy.An RA is an administrative function that registers entities in the PKI. The RAis trusted to identify and authenticate entities according to the CAs policy. Therecan be one or more RAs connected to each CA in the PKI. [wwwEJBCA]The NAF provides PKI functionality in terms of issuing subscriber certificatesbased on the authenticated identity of a subscriber. In order to provide the PKIfunctionality, an OSI Certified15 Open Source Software called Enterprise JavaBeans Certificate Authority (EJBCA) has been used. The EJBCA sources arehosted on Sourceforge.net16 and all downloads include the complete source code.The Enterprise Java Beans Certificate Authority is an advanced open source CA-implementation that is a fully functional Certificate Authority. EJBCA imple-ments the CA part of a PKI according to standards such as X.509 and IETF-PKIX. As such it follows the general PKI concepts closely. The administration ofthe PKI has some EJBCA-specific concepts in order to implement unique flexibil-ity. [wwwEJBCA]The setup and installation process of the EJBCA is very well documented in thedocumentation that can be obtained from the downloaded source files or online athttp://docs.primekey.se/documentation/en/installation.html. EJBCA re-lies on:

• JDK 1.4.x or 1.5.x 17

• Unlimited Strength Jurisdiction Policy Files for your JDK 18

• JBOSS >3.2.6 or 4.0.x (latest tested verison is JBoss 4.0.2) 19

• Ant 1.6.x to build 20

15OSI Certified is a certification mark of the Open Source Initiative16http://sourceforge.net/index.php17http://java.sun.com/javase/downloads/index.jsp18http://java.sun.com/j2se/1.5.0/download.jsp19http://labs.jboss.com/portal/20http://jakarta.apache.org/ant/

85

Chapter 4 Software Implementation

The above prerequisites need to be installed and configured appropriately beforeEJBCA can be connected to the NAF. The installation of the EJBCA itself in-cludes:

• Compiling, jar, war, ear the sources and deploying everything to JBoss

• Generate all certificates, keys, etc needed to run with an initial CA. Ad-ministrative privileges (e.g. root) are needed for the CA-certificate to beinstalled in Javas trust-keystore.

• Import the super administrators certificate in your web browser which isused to access the admin GUI.

For a detailed description of how to setup EJBCA, please refer to the online doc-umentation 21.The interface between PKI Portal (NAF) and the EJBCA is a HTTP interface.The EJBCA has been equipped with a servlet that accepts any incoming post,creates a user with a unique username, and instantly sends back the correspondingcertificate. This servlet is used by the PKI Portal (NAF) to obtain the desiredsubscriber certificates. Authentication is not needed at the EJBCA servlet, asthe NAF carries out authentication of the user and only requests certificates forauthenticated users. The PKI portal functionality of the NAF can be accessedvia the HTTP2IMS GW where a link has been placed that points to the NAFusing a special URL parameter that is recognized by the NAF. The NAF startsthe PKI service upon receiving the URL parameter. Figure 4.7 depicts the NAFPKI service (Certificate Enrollment Service) as one of the services that can bechosen from the list of available services.Subscriber certificates can be used where desired for certificate-based mutual au-thentication between a UE and an AS. If UE and AS are both in possession of asubscriber certificate, the UE may establish a TLS tunnel with the AS as specifiedin [RFC2246]. Note that for this thesis it was assumed, that a client cannot di-rectly access an AS. This is true for ASs residing within the FOKUS Playgroundnetwork. For external ASs however, certificate-based mutual authentication hasbeen identified to be a useful feature for the future. This is why this has beenimplemented as part of this thesis.

21http://docs.primekey.se/documentation/en/installation.html

86

4.3 The Network Application Function

4.3.4 Zn Interface

The Zn interface has already been discussed in section 4.2.5 from the BSF pointof view, where the BSF listens for a NAF initiated Diameter message exchange.The NAF implementation contains the class de.fhg.fokus.gba.naf.DiameterServerwhich has a public method runZn that handles the Zn communication with theBSF. It generates a Diameter BIR and sends it to the BSF. The class de.fhg.fokus.diameter.zn.ZnCommandListener has been implemented to listen for a Zn responsefrom the BSF. The listener notes if a Diameter message with code 310 has beenreceived. The NAF runs some checks on the received response, if this is a validBIA and, in the successful case, tries to read the delivered values from the relevantAVPs.The message format of BIR and BIA can be found in Appendix B. The mostimportant values received form the BSF via the Zn interface are the key materialinside the ME-Key-Material-AVP or UICC-Key-Material-AVP and the GUSS in-side the GBA-UserSecSettings-AVP. For further information on the Zn interface,please refer to Appendix B or [TS29.109].

4.3.5 Ua Interface

The reference point Ua logic has been implemented in the class de.fhg.fokus.gba.naf.uaservlet.UaServlet as a Java servlet. It listens for HTTP/HTTPS requests andexecutes the Ua specified mechanisms upon receiving a valid request. HTTP Di-gest as specified in [RFC2617] is run on the Ua interface in order to authenticatethe client. The NAF server is authenticated to the client by means of a public keycertificate. Valid client requests must contain a HTTP header Authorization

carrying the required security parameters such as username, realm, nonce, etc.Please refer to [RFC2617] for a detailed description of the HTTP Digest mech-nism.The realm contains two parts delimited by a ”@” sign. While the first part ofthe realm is the constant string ”3GPP-bootstrapping”, the second part is theFQDN of the NAF. The NAF is always indicating to UEs that a bootstrappedsecurity association is required by sending a HTTP 401 Unauthorized upon non-valid requests, including a WWW-Authenticate header with the HTTP response.The included realm attribute triggers the UE to run the bootstrapping procedureover interface Ub with the BSF. Once the client has been authenticated and aHTTPS session is established, subsequent requests go through the TLS tunnel.If the key material has expired, a new bootstrapped security association is re-quired. This is indicated by the NAF by sending a HTTP 401 Unauthorized re-

87

Chapter 4 Software Implementation

sponse. If the client receives such a message in response to the HTTP request thatwas protected using the existing bootstrapped security association, this triggersthe UE to re-execute the bootstrapping procedure with the BSF over referencepoint Ub.

4.3.6 Ua* Interface

This non-specified interface replaces the 3GPP specified Ua interface [TS24.109]for non-GBA-capable clients such as standard web browsers. It is a HTTPSinterface and provides full Authentication Proxy functionality. The usual authen-tication mechanisms for the Ua interface is HTTP Digest. This mechanism isreplaced by a cookie based authentication mechanism on the Ua* interface.The Ua* interface servlet (de.fhg.fokus.gba.naf.servlet.NAFservlet) only acceptsHTTPS requests for further processing. All plain HTTP requests are redirectedto the HTTPS port of the NAF. The client need to trust the presented NAFcertificate. In the current Playground setup, this is a self-signed certificate thatcan hardly be trusted. This is why the user is currently presented some warningmessages telling him not to accept the presented NAF certificate. In order toavoid this, a trusted certificate must be used which can easily be obtained fromany known certification authority (for example ”Verisign” 22) or even from the”Fraunhofer-Gesellschaft Root-CA”. For demonstration purposes, a self-signedcertificate is acceptable as the security warnings also demonstrate the integratedsecurity mechanisms. For productive environments, only trustworthy certificatesshould be used.The Ua* servlet reads the B-TID from a common domain cookie (set by theHTTP2IMS GW) that need to be existent if the client has previously been authen-ticated at the HTTP2IMS GW / BSF. If the client request does not contain therequired common domain cookie carrying the B-TID, a HTTP 401 Unauthorized

message is returned to the client. If the B-TID can be obtained from a cookie andthe client request also contains a cookie carrying a NAF specific key Ks NAF, theNAF/AP runs the Zn reference point logic with the BSF in order to obtain thekey material and GUSS for this user (identified by B-TID). If Zn communicationhas been terminated successfully, the NAF/AP disposes of a valid NAF specifickey material and GUSS for that user. This information is stored locally at theNAF/AP in hash tables for further usage. If the client request contains the B-TIDcookie and the Ks NAF cookie, the NAF checks if the Ks NAF obtained from theBSF matches the presented key material of the client. Only if the two keys match,the client is allowed further communication with the NAF/AP. In any other case,

22http://www.verisign.com/

88

4.4 The Demonstration Client Application

GBAutil.jar Utility classes (for example for B-TID and the KeyDerivation Procedure as defined in Appendix C)

Milenage.jar Implementation of the Milenage algorithm for 3GPPauthentication and key generation specified asby [TS35.205]

commons-httpclient.jar A framework for client-side mechanisms of theHTTP protocol.

commons-logging.jar Wrapper around a variety of logging APIimplementations.

log4j.jar Logging API.

Table 4.5: The Client Libraries

a HTTP 401 Unauthorized message is returned. The NAF/AP cache the all Znrelated information for the lifetime of the key material in oder to improve Ua andUa* interface response times.

This section explained the NAF server implementation and all related interfaces.The following section outlines the demonstration client implementation that hasbeen realized due to missing commercial GBA clients.

4.4 The Demonstration Client Application

Although this thesis concentrates on the server side implementation of a GBA in-frastructure, a Demo Client has been implemented to demonstrate the BSF serverinterface Ub and the NAF server interface Ua as specified by 3GPP in [TS24.109].It is a very simple Java Frame (java.awt.Frame) implementation that provides agraphical user interface (GUI). Figure 4.10 shows a screenshot of the GUI. Thisis the initial state of the client, at a stage where neither a Ub run nor a Ua runhas occurred yet.The implementation relies on a few libraries which are listed in table 4.5. GBAu-

til.jar contains classes that are also used by the BSF and the NAF such as classesfor the handling of the Bootstrapping Transcation Identifier, the key material andthe NAF specific key material. The other libraries are external libraries that havenot been written by me. An explanation of what functionalities they provide canbe found in table 4.5.The client implementation is based on sockets that are opened to the BSF andNAF on Ua and Ub interface communication. HTTP messages are exchanged viathe sockets by writing to the output streams and reading from the input streams

89

Chapter 4 Software Implementation

Figure 4.10: The Ua/Ub Client GUI

associated with each socket.Note that the client need to be configured properly by adjusting the configurationfile client.properties which is entirely given in the Appendix section E.3. Withthis file, the BSF location, the NAF location, TLS properties, as well as someuser related security settings (this includes the users IMPI and the shared secretwith the HSS) can be configured.The HTTP Digest and HTTP Digest AKA functionality needed for the interfacesUa and Ub are provided in the classes de.fhg.fokus.gaa.httpdigest.HTTPDigest andde.fhg.fokus.gaa.httpdigest.AKAHTTPDigest respectively.

4.4.1 The Client Ub Interface

The Ub interface and its message exchange between the client and the BSF hasalready been described in section 3.3.1 including example listings of the HTTPmessages created on this reference point. The Ub client functionality has been re-alized in the class UaUbClient.HttpClient. The client opens a HTTP connection tothe BSF upon clicking the ”Send BSF request” button and runs the bootstrappingprocedure with the BSF. It generates HTTP messages as specified in [TS24.109]simulating a GBA-enabled mobile device.

90

4.4 The Demonstration Client Application

To test with maximum flexibility, the HTTP requests are entirely constructed

Figure 4.11: The Client GUI After a Successful Ub Interface Run With the BSF

by the client in the class UaUbClient.HttpClient. It opens a socket to the BSFand uses the in- and output streams to send self generated HTTP messages andreceive the corresponding answers. All HTTP headers are generated manually.This allows for testing the BSF behavior in different error situations by manipu-lating the HTTP headers.Once the bootstrapping procedure has successfully terminated, the client calcu-lates the key material using GBAutil.jar and stores the key material for furtherusage with the NAF.Figure 4.11 shows the Client GUI after a Ub run has successfully terminated.The text field labeled ”BTID” shows the client-generated B-TID. This is used asusername in a subsequent Ua interface run. The key material Ks has already been

91

Chapter 4 Software Implementation

generated but the textfield labeled Ks NAF is still empty. It will be filled whenthe NAF specific key material Ks NAF is generated upon a Ua interface run. Thisis shown in figure 4.12.Note that the HTTP 401 Unautorized message returned by the BSF, which isshown in the textfield ”Results”, in figure 4.11 contains the nonce that is used bythe client to generate the response digest. The HTTP 200 OK message carries aXML document in the body that has been send by the BSF. This so-called Boot-strapping Information contains the B-TID which must be identical to the clientgenerated B-TID. The Bootstrapping Information also contains the lifetime of thekey material in seconds. In this testrun, the lifetime was set to 3600 seconds whichis one hour. This is why the Expires header is set to one hour after the currenttime.

4.4.2 The Client Ua Interface

The Ua interface logic has been implemented in the class UaUbClient.NAFHttpClient. Upon clicking the ”Send NAF request” button, the client runs the Ualogic with the NAF. Obviously, this can only be terminated successfully, if thebootstrapping procedure with the BSF has been run successfully beforehand (the”Send BSF request” button).As shown in figure 4.12, the NAF specific key material is now generated from

the key material Ks. Together with the username B-TID, the client runs HTTPDigest with the NAF.The client can furthermore be configured to use TLS to prevent eavesdropping,tampering, and message forgery. TLS is generally used to provide privacy anddata integrity between two communicating parties. Please refer to appendix E.3for a full example configuration file. To configure the client for TLS usage, setthe property USEsecureNAF in file client.properties to true. You will then need toprovide a valid TLS port for the target NAF.The client can additionally be configured to either accept TLS connections for allNAF servers or only for those configured with a keystore. For testing, demonstra-tion, and prototype purposes it is useful to accept TLS connections for all servers.If the client needs to be configured to only accept TLS connections with a cer-tain set of NAF servers, a Java keystore can be used to store cryptographic keysand certificates. Third party (NAF) public key certificates can be imported intothe keystore (for example by using keytool 23). Such certificates are then called”trusted certificates” because the keystore owner trusts that the public key in the

23keytool - Key and Certificate Management Tool, http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html

92

4.4 The Demonstration Client Application

Figure 4.12: The Client GUI After a Successful Ub Interface Run

certificate indeed belongs to the identity identified by the subject (owner) of thecertificate. This type of certificates are used by the client implementation to au-thenticate NAFs in TLS handshaking. So to only trust a single NAF, the NAF‘scertificate would need to be imported into the keystore. The client will thenneed to be configured with the keystore details. To do this, set the parametersACCEPTallNAFservers=false, javax.net.ssl.trustStore=path-to-keystoreand javax.net.ssl.trustStorePassword=the-password in the client proper-ties file client.properties.

You should now also be familiar with the demonstration client implementation.By using the two buttons ”Send BSF request” and ”Send NAF request”, theUb and Ua reference points logic can be run several times and independently

93

Chapter 4 Software Implementation

from each other (Ub need to be run once before the first Ua run can take place).This is highly suitable for demonstrating the GBA functionality and testing theentire infrastructure, e.g. by tracing and analyzing the transfered packets using”Wireshark”24. As the client is very simple and only contains a minimum set ofrequired functionality, it can easily be understood and extended if required.

4.5 Summary

This chapter gave insights into the structure of the implementation. The servercomponents, mainly BSF and NAF with their interfaces have been discussed indetail. Whenever possible, references to the Java classes of the implementationhave been given. This allows for a profound understanding of the implementation.The following chapter describes the validation of this thesis’s implementation.This is the last step missing for a full implementation description which startedwith the design (chapter 3), was followed by the implementation (chapter 4), andwhich will be finished with the following validation (chapter 5).

24free software protocol analyzer, http://www.wireshark.org/

94

Chapter 5

Software Validation Within theFOKUS Open IMS Playground

In this chapter the software validation will be described. The implementation hasbeen tested with several components from the FOKUS Open IMS Playground.The Diameter interface Zh has been validated with the live installation of FHoSSwhich is serving the FOKUS IMS core within the Playground.The client interfaces Ua and Ub have been validated with the client introduced bysection 4.4 and two standard up to date Internet browsers (Firefox and InternetExplorer).The reverse proxy and authentication proxy functionality of the NAF has beentested by establishing connections to several Application Servers running in thePlayground. Among the services that have been tested, the Smart Messengerand the O2 Portal can be found. Also, retrieving a contact list from the FOKUSXDMS has been shown successfully.Each of the following sections describes a validation scenario that has been carriedout to prove the stable functioning of this thesis’s authentication infrastructureimplementation.

5.1 SSO for All AP-Connected IMS Services

The implementation provides Single Sign-On for all described IMS services on theUa* and Ub* interface. This means that as soon as the user has authenticated forservice access at the HTTP2IMS GW, there is no need to provide the credentialsagain for the lifetime of the key material.Figure 5.1 shows the entire validation setup within the Open IMS Playground.For every network component the IP address, its hostname, as well as relevant

95

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

ports have been listed. In this setup SSO is provided for the XDMS contact listservice, the O2 FMC Portal service, and the Smart Messenger. The services willbe described in more detail in the following sections.

The SSO mechanism works as follows: if the user initially enters for example

Smart Messenger AS

Ub

Zn

HTTP2IMS GW + BSF

Zh

FHoSS

Firefox

193.175.134.88ramson

http: 8080diameter: 3868

193.175.134.87absinthe

http: 8080diameter: 3868

193.175.134.200o2-imshttp: 8888

O2 FMC AS

XDMS193.175.134.200o2-imshttp: 8080

193.175.134.83pellmellhttp: 8080

193.175.134.88ramson

http: 8090diameter: 3869

Ua

Ub*

Ua*

NAF / APGBA Client

Figure 5.1: The Validation Setup Within the FOKUS Open IMS Playground

the URL of the Smart Messenger into his browser, the request is directed tothe HTTP2IMS GW in order to carry out authentication. The user enters hiscredentials at the displayed login page and can select any of the available serviceswith a desired UID. Alternatively, the HTTP2IMS GW can redirect the userback to the initial URL (Smart Messenger) through the NAF. In both cases, theuser is now displayed the service site. At this stage, the user’s browser disposesof the authentication cookie that can be used for authentication with any NAFwithin the the security domain of the BSF. If the user now enters the URL ofany other service, for example the O2 Portal URL, he is displayed the O2 Portalsite directly, because the NAF recognizes the common domain cookie and allowscommunication with the AS (given that the user is authorized to use this type ofservice and the key material has not yet expired).The described scenario has been tested successfully within the Playground anddemonstrates the SSO capability achieved by this thesis’s GBA implementationdeployment.The following sections outline the validation scenarios for the FHoSS interaction,the HTTP interfaces, and the connected demonstration services.

96

5.2 Interaction With the FHoSS

5.2 Interaction With the FHoSS

The Fraunhofer Home Subscriber Server1 implements (among others) the Zh inter-face. Like BSF and NAF, the FHoSS uses a Java Diameter peer to send requestsand retrieve responses via different command listeners.Intensive testing has been carried out on the Diameter interface Zh. The stabilityof the Diameter communication is essential, because the other parts of the infras-tructure depend on it. All user related information (AVs, GUSS) is stored in theHSS database. Without this data it is impossible for the entire system to functionas an authentication infrastructure.Figure 5.2 and 5.3 show successful Diameter Zh communication in a Wireshark2

trace. The MAR contains, as the most important AVP the User-Name AVP, which

Figure 5.2: The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-Request

carries the requesting user’s IMPI. Based on the provided IMPI, the FHoSS re-

1http://www.openimscore.org/docs/FHoSS/index.html2free software protocol analyzer, http://www.wireshark.org/

97

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

turns a MAA which carries the necessary security values for the BSF to provide thebootstrapping procedure service. The MAA contains the authentication schemewhich is Digest-AKAv1-MD5, a nonce value, a Confidentiality Key Ck and an In-tegrity Key Ik. Please refer to figure 5.3 for the Wireshark trace with focus onthe MAA.The BSF implementation has been found to work in a stable and reliable manner

Figure 5.3: The Zh Interface Wireshark Trace - Diameter Multimedia-Auth-Answer

with the FHoSS. After startup, the BSF requires a few seconds to find the FoHSSand exchange Diameter Capabilities-Exchange-Request and Capabilities-Ex

change-Anwser whith it. From then on, Diameter Device-Watchdog-Request

and Device-Watchdog-Anwser messages are exchanged at a rate specified in theDiameter peer configuration file DiameterPeer.xml as given by Appendix E.4.The following screen shot shows the FHoSS GUSS provisioning site. For everysubscriber the GUSS can be set as displayed in figure 5.4. In this example theuser identified be the IMPI wahle@open-ims.org has USS (User Security Set-

98

5.2 Interaction With the FHoSS

tings) for two service types: PKI Portal and Authentication Proxy. These twoservices are the only services allowed to be given by a NAF that is a member ofnafgroup1. The NAF group is an operator internal group designator for a groupof NAFs the USS are valid for. Additionally, the PKI Portal authorization flagfor authentication has been set. This service is additionally allowed. The flags donot have any relevance for the Authentication Proxy service.The UICC type is set to basic GBA. GBA U (UICC based GBA) is currently

Figure 5.4: The FHoSS GUSS Provisioning Website

not supported by the GBA implementation. The lifetime for the key material hasbeen set to one hour (3600 seconds).Different GUSS have been set for different testuser identities in order to validatethe GBA implementation and GUSS evaluation at the NAF. The implementationhas been found to work stably for a broad range of different settings.

99

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

5.3 Interface Ua and Ub Validation

Screenshots of successful Ua and Ub interface runs from the clients perspectivehave already been shown in section 4.4. The demonstration client has been usedto carry out many testruns while manipulating HTTP headers and their contents.The BSF and NAF could therefore be tested in various error situations. Bothserver components have now reached a reasonable stability. In case of erroneousHTTP messages targeting the GBA servers, both BSF and NAF deny authentica-tion and keep challenging the user with HTTP 401 Unauthorized responses untila valid request is received.

The extensive testing and validation of the interfaces Ua* and Ub*, will nowbe proven by listing and describing a set of successfully connected Open IMSPlayground services. This will be described in the next sections.

5.4 The O2 FMC Portal Service

Based on the ongoing architectural discussion about Next Generation Networks,service architectures, and emerging service delivery platforms for fixed and mobileIP networks, mobile operators use the FOKUS Open IMS Playground to gaininsights into the field of Fixed Mobile Convergence (FMC). FOKUS developedseveral FMC services for O2 Germany, which operates a GSM/GPRS/UMTS mo-bile network providing a fixed line voice substitution solution as well as upcomingDSL wireline access.The FMC services are offered via a web page (O2 Portal). To access the O2 Por-tal, the user has to authenticate. A login (username and password) need to beprovisioned for every subscriber.In order to simplify the O2 login and to demonstrate and validate this thesis’sGBA implementation, two scenarios have been realized: The user can login viathe normal HTTP2IMS GW page as shown in figure 4.6 or via the O2 Portal page.If the user logs in via the HTTP2IMS GW and selects the O2 Portal service, he isredirected to the O2 FMC Portal page which can welcome the user based on theX-3GPP-Asserted-Identity HTTP header that is inserted by the NAF into therequest toward the O2 AS. The O2 application extracts the header and recognizesthe user. If the X-3GPP-Asserted-Identity HTTP is missing, the O2 Portaldisplays a login screen. Figure 5.5 shows the O2 Portal welcome screen if a userhas been recognized successfully.

100

5.4 The O2 FMC Portal Service

Furthermore, the idea was that it should be possible to log in (using the same

Figure 5.5: The O2 FMC Portal Welcome Page Screenshot

login credentials) at both sites (the HTTP2IMS GW and the O2 Portal). Thismeans that the O2 login provisioning, that had to be done by a O2 service ad-ministrator, can now be omitted.If the user logs in via the normal HTTP2IMS GW, it needs one more click toselect the O2 Portal from the list of allowed services. The advantage from usingthe HTTP2IMS GW is that the user has the chance to select a desired UID tobe used with the service. The disadvantage is that the user is redirected to theHTTP2IMS GW login page which is operated by the IMS operator (FOKUS) andnot O2. This means that it is not a O2-branded site. This is not desired in theO2 case. That is why the second scenario has been implemented. The user canlogin via the O2 Portal and still receive the necessary cookie to be authenticatedat the NAF and use the O2 services. For this approach the HTTP2IMS GW loginpage has been replaced with the O2 page, keeping the gateway functionalities.The drawback from this approach is that the user may not choose from a list ofUIDs associated with its IMS subscription. A default UID (the first in the lists ofUIDs) is selected instead.However, in both cases, the central data and identity store HSS provides the GBAcomponents with the necessary security values to allow for secure authentication,authorization, and service delivery.

101

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

To validate the GBA implementation capabilities, the O2 FMC web-based mail-box service is used. It offers a web-based user interface where, among otherfeatures, the welcome text for callers can be recorded and saved. Figure 5.6 showsa screenshot of this service.

Figure 5.6: The O2 FMC Portal Offered Web Mailbox Service

The O2 page login, as well as the welcome message recording, listening, and saving(all via the GBA) has been tested successfully.

5.5 The Smart Messenger Service

The Smart Messenger Service is one of the FOKUS Open IMS Playground demon-stration services that is used to show the Playground capabilities. It is a multi-channel message delivery service. This means, that a user-defined message canbe delivered over various communication channels, each of them using a differentand independent transmission technology. Residing on top of of the FOKUS Open

102

5.5 The Smart Messenger Service

Communication Server (OCS), a Parlay Gateway implementation, it uses Parlayinterfaces to send a user-defined message to different targets at the same time.The service is offered via an application server residing within the Playground(pellmell, see figure 5.1). It has been connected to the NAF. The applicationserver displays a web page to the user upon request where the message to bedelivered, as well as the receiving parties can be configured. Figure 5.7 shows ascreenshot of the service web page. Different receivers can be entered. Allowed

Figure 5.7: The FOKUS Open IMS Playground Smart Messenger Demo Screenshoot

values are email addresses, telephone numbers, and SIP addresses. In the dropdown fields, one of the following can be selected:

• Voice - reads the entered message to the receiving party by Text-to-Speech,technology

• SMS - sends an SMS to the entered mobile number,

• Textmessage - sends an instant message,

• Email - sends an email.

103

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

The service uses the User Interaction interface, the Call Control interface as wellas the Generic Messaging interface of Parlay. The Smart Messenger is also aClick2Dial application.The Smart Messenger has so far been secured by a login screen. Login data in-cluding username and password had to be provisioned for every single user thatwas subscribed for the service. With the deployment of this thesis’s GBA im-plementation this has been improved. As authentication and authorization arehandled by BSF and NAF, the AS that is hosting the Smart Messenger has beenrelieved from this task. The AS is accessible via the AP (NAF) which inserts theX-3GPP-asserted-ID HTTP header into the request targeting the AS. The ASreads this user identity from the requests and can offer personalized services basedon the identity. This assumes that the service is only accessible via the AP.As the AP - AS connection is inside the trusted FOKUS IMS Playground oper-ator network, a plain HTTP connection is sufficient. If the connection has to beestablished via untrusted networks, confidentiality and integrity protection canbe provided using NDS/IP mechanisms as specified in [TS33.210]. Because theAP terminates the TLS tunnel from the UE, it is also possible to establish a TLStunnel for the reference point between the AP and the AS.The demonstration scenario for the validation of the GBA implementation is touse the Smart Messenger to send a voice message to a recipient. The contactinformation and message text is configured by a user that has been authenticatedvia the GBA infrastructure. All traffic is directed through the AP as the useraccesses the Smart Messenger, configures the contact and message details, andfinally sends the message.

The described scenario has been tested successfully.

5.6 The XML Document Management Service

The XDM architecture has been introduced in section 3.6 and is depicted by figure3.11. It has been outlined how the documents that are stored on a XDMS can beaccessed and changed (using XCAP).Fraunhofer FOKUS has developed the FOKUS XDMS which also implements anAggregation Proxy. In this validation setup it has been tried to obtain a contactlist (well-structured XML document residing on the FOKUS XDMS that containsthe user’s contacts) from the XDMS while authentication is handled by the GBA.A standard Mozilla Firefox (version 1.5.0.9) 3 browser has been used to retrieve

3http://www.mozilla-europe.org/en/

104

5.6 The XML Document Management Service

Figure 5.8: Wireshark Trace of AP - XDMS Contact List Retrieval Communication

the contact list. At this stage it is nothing more than an XML document con-taining the contacts of the requester, but it shows the successful interworking ofthe OMA XDM infrastructure and the 3GPP GBA. The validation scenario startswith editing the contact list of the user gba@open-ims.org. This is done using aSIP softphone such as Eyebeam 4. The list is edited and stored on the XDMS. Itis then retrieved from the XDMS via the AP upon request.As stated above a Mozilla Firefox web browser has been used to request the list.Authentication, authorization, and channel security is handled by the BSF andthe AP by applying the Bootstrapping Procedure and extended GBA mechanismsas outlined before. The XDMS selects the contact list based on the identity de-livered in the X-3GPP-Asserted-Identity HTTP header that is inserted into therequest by the AP.Figure 5.8 shows the HTTP request from the AP to the XDMS. Note that theX-3GPP-Asserted-Identity header contains the user identity.The request is received by the XDMS and as the it origines from within the opera-tors network (the Playground in this case) and contains a valid X-3GPP-Asserted-

Identity header, the XDMS returns the contact list for gba@open-ims.org in aHTTP 200 OK response. The list is a XML document that is carried in the body ofthe response. The list can now be displayed in the browser or can be downloadedto a desired location. Figure 5.9 shows the decoded packet flow of the request andthe corresponding response.

The described validation scenario has been tested successfully.

4http://www.xten.com/index.php?menu=products&smenu=eyebeam

105

Chapter 5 Software Validation Within the FOKUS Open IMS Playground

Figure 5.9: The Decoded HTTP GET and 200 OK Response Flow

This chapter provided a clear view of how the implementation has been validatedwithin the FOKUS Open IMS Playground showing several screenshots and packetflow traces.The last chapter will summarize this thesis and describe some topics that can beaddressed by future efforts.

106

Chapter 6

Summary and Outlook

This thesis has introduced the design and implementation of authenticated, autho-rized and secured HTTP service access to the IP Multimedia Subsystem using aGeneric Bootstrapping Architecture. After outlining what the IMS is and describ-ing its role as vital part of the ETSI TISPAN specified Next Generation Networkarchitecture, the thesis explained the core IMS network elements and its generalstructure. Furthermore, it gave insights into the relevant standardization organi-zations and the published specifications related to the GBA. In a clear and concisemanner, this thesis has described the design of the actual implementation and itspractical realization and also gave details on its validation within the FraunhoferFOKUS Open IMS Playground.The design and implementation of the GBA on the one hand closely follows therelevant specifications and implements the specified GBA infrastructure and aGBA client. On the other hand it enhances the specified GBA infrastructure byintroducing a HTTP to IMS gateway (HTTP2IMS GW) which enables non-GBA-capable clients such as standard web browsers to use the services secured by theGBA network elements. It has been outlined that this approach is confrontedwith additional security threats.IMS is facing some skepticism in the Internet and peer-to-peer worlds concern-ing the practicality of such systems and the return on investment. Nevertheless,since IMS is already in trial phases with operators worldwide, we will soon knowif this will be the infrastructure of choice for future telecommunication systems.Fraunhofer FOKUS has positioned itself very well running a unique IMS testbedfor the benefit of academic and industry initiatives. This thesis has contributedto the testbed by defining and implementing a service layer access authenticationinfrastructure, that is based on specifications spanning multiple standardizationorganizations.The industry is in need for academic efforts in this area, which is proven by the factthat some of this thesis’s implementation results have already been sold, thanks

107

Summary and Outlook

to some promotion by my supervisors, as a prototype implementation to a majorindustry player.

Future efforts certainly need to be undertaken in the client area. Currently, thereare no commercial IMS clients publicly available that fully support the GenericBootstrapping Architecture.With regard to this thesis’s implementation, future work should concentrate onthe diversity of different authentication methods (or GBA profiles) that can beused with this GBA implementation. HTTP Digest authentication should alsobe supported on the Ub interface which means porting the NAF HTTP Digestimplementation to the BSF. On the Zh interface however, this requires adapta-tions to the HSS. The FHoSS is currently being adapted to support HTTP Digestauthentication.On the Ua interface, the NAF should also support pre-shared key TLS as well asthe certificate-based authentication of clients as additional authentication meth-ods. With the PKI Portal functionality, the NAF/AP can already issue subscribercertificates. The possibility to use such certificates at the NAF and/or the Appli-cation Servers to identify the requesting entity, would expand the set of possibleapplication scenarios.The GBA demonstration client is currently based on a unsecured configuration file(unsecured soft-ISIM) that provides the client with the necessary security values(IMPI, shared secret with HSS) for identifying and authenticating the user. Fu-ture work can replace the soft-ISIM with a real UICC card, that provides securestorage. This could be done using a mobile phone (the GBA client runs on thedevice) or a card reader as shown in figure 4.1.Another future issue is the implementation of a 3GPP - Liberty Alliance inter-working infrastructure. The Liberty Alliance specified very interesting conceptsfor Federated Identity Management, Web Services and Cross Domain Single Sign-On. In Release 7, the 3GPP GBA is specified with Web Services support andinterworking with the Liberty Alliance. By integration of Liberty Identity andService Providers into a 3GPP GBA/GAA, an extension of the IMS centric boot-strapping procedure toward Internet services that can be hosted in arbitrary loca-tions becomes possible. This contributes to the overall IMS vision of fixed mobileconverged services and the merger of paradigms.

108

Appendix A

German Summary

Im Folgenden, wie vom Prufungsausschuss gefordert, eine deutsche Zusammenfas-sung der vorliegenden Diplomarbeit. Das Thema der Arbeit lautet ubersetzt:”Entwurf und Implementierung einer HTTP-basierten Authentifizierungsinfra-struktur fur IP Multimedia Subsystem Dienstzugang”. Wie der Titel erkennenlasst, ist neben der theoretischen Betrachtung der Sachverhalte, eine praktischeImplementierung Teil der Diplomarbeit.Das IP Multimedia Subsystem (IMS) ist ein auf dem Internet Protokoll (IP)basierendes System, das den standardisierter Zugriff auf Multimedia- und Sprach-dienste aus unterschiedlichen Netzwerken erlaubt. Es ist spezifiziert von 3GPP,dem Third Generation Partnership Projekt und dessen Tochterprojekt 3GPP2,welches Spezifikationen fur Nord Amerika und Asien veroffentlicht. IMS stelltaußerdem die Basis fur den Next Generation Network Release 1 dar, der vonETSI TISPAN (European Telecommunications Standards Institute Telecoms andInternet converged Services and Protocols for Advanced Networks) spezifiziertwurde.Das Fraunhofer FOKUS Institut verfugt uber ein eigenes IMS Testlabor, denFOKUS Open IMS Playground. Das Labor stellt ein komplettes IMS Systemzu Verfugung, das aus Eigenentwicklungen und Partnerkomponenten aufgebautwurde und zu Forschungszwecken und fur Industrieprojekte genutzt wird. NebenSIP (Session Initiation Protokoll), kann im IMS das Hypertext Transfer Protocol(HTTP) eingesetzt werden, um Dienste zur Verfugung zu stellen. Viele SIP-basierte Dienste stellen außerdem Konfigurationswebseiten zur Verfugung, umPersonalisierung zu ermoglichen und generelle Einstellungen vorzunehmen. Aufdiese Seiten kann mit HTTP zugegriffen werden.Das Ziel der vorliegenden Arbeit ist es, eine Infrastruktur zu beschreiben und zuimplementieren, die Authentifizierung und Autorisierung von Nutzern, die aufgenannte HTTP-basierte Dienste zugreifen mochten, sicherzustellen. Es wirddazu die bei 3GPP/ 3GPP2 und ETSI TISPAN verwandte Generic Bootstrap-

109

Appendix A German Summary

ping Architecture (GBA) umgesetzt, die es ermoglicht, dynamisch Schlusselpaarefur eine sichere HTTP Verbindung zwischen Server und Nutzer auszuhandeln.Die Schlusselpaare konnen dann nachfolgend verwand werden, um den Nutzergegenuber Diensten zu authentifizieren und den Nachrichtenaustausch zu ver-schlusseln.Die Arbeit folgt einer klaren Struktur. Zu Beginn werden das IMS und seineVorteile fur die Betreiber, als auch die Nutzer vorgestellt. Es folgt eine ausfuhrlicheBeschreibung der relevanten Standardisierungsorganisationen, sowie der von diesenveroffentlichten Spezifikationen, die fur die Arbeit von Bedeutung sind. Es wirddann der Entwurf der Implementierung dargelegt, sowie die praktische Umsetzungbeschrieben. Den Abschluss der Arbeit bildet ein Validierungskapitel, in welchemdie Integration der Implementierung in den Fraunhofer FOKUS Open IMS Play-ground und die Anbindung an bestehende Dienste beschrieben wird.Die Implementierung umfasst mehr als 15000 Zeilen Java Code, der bereits in In-dustrieprojekten eingesetzt wird. Eine wesentliche Authentifizierungsserverkom-ponente wurde, mit der dazugehorigen Dokumentation, an einen der fuhrendenTelekommunikationsanbieter als Prototypenentwicklung verkauft.

110

Appendix B

Diameter Commands

This Appendix describes the Diameter Commands used by BSF and NAF on theinterfaces Zh and Zn. The chapter has mainly been taken from [TS29.109]

B.1 Multimedia-Auth-Request (MAR)

The BSF shall send the following Bootstrapping-Request to the HSS in the formatof Multimedia-Auth-Request (MAR) message. The content of the message is givenbelow in the same format as in 3GPP TS 29.229. The curly brackets indicatemandatory AVPs. The square brackets indicate optional AVPs. The ”address of”refers to the Fully Qualified Host Name (FQDN).

<Multimedia−Auth−Request> ::=<Diameter Header: 303, REQ, PXY, 16777221 >< Session−Id >{ Vendor− Specific − Application −Id }{ Auth−Session−State } ; NO STATE MAINTAINED{ Origin −Host } ; Address of BSF{ Origin −Realm } ; Realm of BSF{ Destination −Realm } ; Realm of HSS[ Destination −Host ] ; Address of the HSS{ User−Name } ; IMPI from UE[ GUSS−Timestamp ] ; Timestamp of GUSS in BSF∗[ AVP ]∗[ Proxy−Info ]∗[ Route−Record ]

The content of mandatory Vendor-Specific-Application-ID is:

<Vendor−Specific−Application−Id>::=<AVP header: 260>1∗ [Vendor−Id] ; 3GPP is 104150∗1 {Auth− Application−Id} ; 167772210∗1 {Acct− Application −Id} ; Omitted

111

Appendix B Diameter Commands

B.2 Multimedia-Auth-Answer (MAA)

The HSS shall send the following Bootstrapping-Answer message in the format ofMultimedia-Auth-Answer (MAA) message back to the BSF.

< Multimedia−Auth−Answer> ::= < Diameter Header: 303, PXY, 16777221 >< Session−Id >{ Vendor− Specific − Application −Id }[ Result −Code ][ Experimental −Result ]{ Auth−Session−State } ; NO STATE MAINTAINED{ Origin −Host } ; Address of HSS{ Origin −Realm } ; Realm of HSS[ User−Name ] ; IMPI∗[ SIP−Auth−Data−Item ][ GBA−UserSecSettings ] ; GUSS∗[ AVP ]∗[ Proxy−Info ]∗[ Route−Record ]

B.3 Bootstrapping-Info-Request (BIR)

The NAF shall send a Bootstrapping-Info-Request message (BIR) to the BSF. Thecontent of the message is given here in the same format as in 3GPP [TS29.229].The curly brackets indicate mandatory AVPs. The square brackets indicate op-tional AVP. The address refers to the Fully Qualified Host Name (FQDN).

< Bootstrapping−Info−Request> ::=<Diameter Header: 310, REQ, PXY, 16777220 >< Session−Id >{ Vendor− Specific − Application −Id }{ Origin −Host } ; Address of NAF{ Origin −Realm } ; Realm of NAF{ Destination −Realm } ; Realm of BSF[ Destination −Host ] ; Address of the BSF∗ [ GAA−Service− Identifier ] ; Service identifiers{ Transaction − Identifier } ; B−TID{ NAF−Id } ; NAF ID[ GBA U−Awareness−Indicator ] ; GBA U awareness of the NAF∗[ AVP ]∗[ Proxy−Info ]∗[ Route−Record ]

The content of Vendor-Specific-Application-ID is:

<Vendor−Specific−Application−Id>::=<AVP header: 260>1∗ [Vendor−Id] ; 3GPP is 104150∗1 {Auth− Application−Id} ; 167772200∗1 {Acct− Application −Id} ; Omitted

112

B.4 Bootstrapping-Info-Answer (BIA)

The Destination-Realm AVP is set to the subscriber’s BSF. The address of theBSF is extracted from the B-TID.The NAF indicates the GAA services for which the information is retrieved byGAA-Service-Identifier AVPs. The Bootstrapping Transaction Identifier definesthe earlier bootstrapping procedure execution.

B.4 Bootstrapping-Info-Answer (BIA)

Upon receiving a BIR, the BSF shall send a Bootstrapping-Info-Answer message(BIA) back to the NAF.

< Boostrapping−Info−Answer> ::= < Diameter Header: 310, PXY, 16777220 >< Session−Id >{ Vendor− Specific − Application −Id }[ Result −Code ][ Experimental −Result ]{ Origin −Host } ; Address of BSF{ Origin −Realm } ; Realm of BSF[ User−Name ] ; IMPI[ ME−Key−Material ] ; Required[ UICC−Key−Material ] ; Conditional[ Key−ExpiryTime ] ; Time of expiry[ BootstrapInfoCreationTime ] ; Bootstrapinfo creation time[ GBA−UserSecSettings ] ; Selected USSs[ GBA−Type ] ; GBA type used in bootstrapping∗[ AVP ]∗[ Proxy−Info ]∗[ Route−Record ]

The BSF may or may not send the User-name AVP (IMPI) according its con-figuration. The mandatory common key material with the ME (Ks NAF orKs ext NAF) is sent in the ME-Key-Material AVP. The common key materialwith the UICC (Ks int NAF) is optionally sent in the UICC-Key-Material AVPonly if the ”uiccType” tag in bsfInfo from the HSS is set to ”GBA U”.The Key-ExpiryTime AVP contains the expiry time of the Bootstrapping infor-mation in the BSF according its configuration. The expiry time is representedaccording the Diameter Time data format in seconds that have passed since 0hon January 1, 1900 UTC. If a special key lifetime value is given in the ”lifeTime”tag inside the bsfInfo from the HSS in bootstraping procedure, it is used insteadof the BSF default configuration value when the expiry time is calculated.The BootstrapInfoCreationTime AVP contains the bootstrapinfo creation time,i.e., creation time of the Bootstrapping information in the BSF. The bootstrap-info creation time is represented in seconds that have passed since January 1, 190000:00:00.000 UTC.The BSF selects the appropriate User Security Settings (if any) to the GBA-UserSecSettings AVP from stored GAA-UserSecSettings in Bootstrapping infor-

113

Appendix B Diameter Commands

mation according the GBA-Service-Identifier AVPs in the request message.The BSF shall indicate the type of used authentication in the bootstrapping pro-cedure to the NAF in GBA-Type, if other than 3G GBA type has been performed.

114

Appendix C

Specification of the Key DerivationProcedure

This normative definition of the key derivation function and NAF specific keyshas been taken from [TS33.220].

C.1 Introduction

This annex specifies the key derivation function (KDF) that is used in the NAFspecific key derivation in both GBA (i.e. GBA ME) and GBA U. The key deriva-tion function defined in the annex takes the following assumptions:

1. the input parameters to the key derivation functions are octet strings - notbit strings of arbitrary length:

2. a single input parameter will have lengths no greater than 65535 octets.

C.2 Generic Key Derivation Function

The input parameters and their lengths shall be concatenated into a string S asfollows:

115

Appendix C Specification of the Key Derivation Procedure

1. The length of each input parameter in octets shall be encoded into two-octetstring:

a) express the number of octets in input parameter Pi as a number kin the range [0, 65535].

b) Li is then a two-octet representation of the number k, with the mostsignificant bit of the first octet of Li equal to the most significant bitof k, and the least significant bit of the second octet of Li equal to theleast significant bit of k, EXAMPLE: If Pi contains 258 octets then Liwill be the two-octet string 0x01 0x02.

2. String S shall be constructed from n input parameters as follows:

S = FC||P0||L0||P1||L1||P2||L2||P3||L3||...||Pn||Ln

where

FC is single octet used to distinguish between different instances of thealgorithm,

FC is single octet used to distinguish between different instances of thealgorithm,

P0 is a static ASCII-encoded string,

L0 is the two octet representation of the length of the P0,

P1 ... Pn are the n input parameters, and

L1 ... Ln are the two-octet representations of the corresponding inputparameters.

3. The final output, i.e. the derived key is equal to HMAC-SHA-256 computedon the string S using the key Key:

derivedkey = HMAC − SHA− 256(Key, S)

C.2.1 Input Parameter Encoding

A character string shall be encoded to an octet string according to UTF-8 encodingrules as specified in IETF RFC 3629.

116

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

C.3 NAF Specific Key Derivation in GBA andGBA U

In GBA and GBA U, the input parameters for the key derivation function shallbe the following:

- FC = 0x01

- P1 = RAND,

- L1 = length of RAND is 16 octets (i.e. 0x00 0x10),

- P2 = IMPI encoded to an octet string using UTF-8 encoding (see clauseB.2.1),

- L2 = length of IMPI is variable (not greater that 65535),

- P3 = NAF ID with the FQDN part of the NAF ID encoded to an octetstring using UTF-8 encoding (see clause B.2.1), and

- L3 = length of NAF ID is variable (not greater that 65535).

In the key derivation of Ks NAF as specified in clause 4 and Ks ext NAF asspecified in clause 5,

- P0 = ”gba-me” (i.e. 0x67 0x62 0x61 0x2d 0x6d 0x65), and

- L0 = length of P0 is 6 octets (i.e., 0x00 0x06).

In the key derivation of Ks int NAF as specified in clause 5,

- P0 = ”gba-u” (i.e. 0x67 0x62 0x61 0x2d 0x75), and

- L0 = length of P0 is 5 octets (i.e., 0x00 0x05).

The Key to be used in key derivation shall be:

- Ks (i.e. CK||IK concatenated) as specified in clauses 4 and 5,

NOTE: In the specification this function is denoted as:

Ks NAF = KDF (Ks, ”gba−me”, RAND, IMPI, NAF Id),

Ks ext NAF = KDF (Ks, ”gba−me”, RAND, IMPI, NAF Id), and

Ks int NAF = KDF (Ks, ”gba− u”, RAND, IMPI, NAF Id).

117

Appendix C Specification of the Key Derivation Procedure

118

Appendix D

GBA-UserSecSettings XMLdefinition

This Appendix has entirely been taken from [TS29.109].

This annex contains the XML schema definition for an XML document carryingthe GBA User Security Settings inside GBA-UserSecSettings AVP in Zh and Zninterface.

<?xml version =”1.0” encoding=”UTF−8”?><xs:schema targetNamespace=”guss−schema−of−3gpp−gaa”

xmlns:tns=”guss−schema−of−3gpp−gaa”xmlns:xs=”http://www.w3.org/2001/XMLSchema”elementFormDefault=”qualified”attributeFormDefault=” unqualified ”>

<!−− This import brings in the XML language attribute xml:lang−−><xs:import namespace=”http://www.w3.org/XML/1998/namespace”

schemaLocation=”http://www.w3.org/2001/xml.xsd”/>

<xs:complexType name=”tExtension”><xs:sequence>

<xs:any processContents=”lax” minOccurs=”0” maxOccurs=”unbounded”/></xs:sequence>

</xs:complexType>

<xs:complexType name=”tGUSSExtension”><xs:sequence>

<xs:element name=”timestamp” type=”xs:dateTime” minOccurs=”0”/><xs:element name=”Extension” type=”tExtension” minOccurs=”0”/>

</xs:sequence></xs:complexType>

<xs:complexType name=”tUSSExtension”><xs:sequence>

<xs:element name=”keyChoice” type=”xs:string” minOccurs=”0” /><xs:element name=”Extension” type=”tExtension” minOccurs=”0”/>

</xs:sequence></xs:complexType>

<!−− The whole user’s GBA specific data set −−>< xs:complexType name=”guss”>

< xs:sequence >< xs:element ref =” bsfInfo ” minOccurs=”0”/>< xs:element ref =” ussList ”/>< xs:element name=”Extension” type=”tGUSSExtension” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence >

119

Appendix D GBA-UserSecSettings XML definition

< xs:attribute name=”id” type=” xs:string ”/></ xs:complexType>

<!−− BSF specific information element −−>< xs:complexType name=” bsfInfo ”>

< xs:sequence >< xs:element name=”uiccType” type=” xs:string ” minOccurs=”0” />< xs:element name=” lifeTime ” type=” xs:integer ” minOccurs=”0” />< xs:element name=”Extension” type=” tExtension ” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence ></ xs:complexType>

<!−−List of all users individual User Security Settings −−>< xs:complexType name=” ussList ”>

< xs:sequence minOccurs=”0” maxOccurs=”unbounded”>< xs:element ref =”uss”/>< xs:element name=”Extension” type=” tExtension ” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence ></ xs:complexType>

<!−− User Security Setting data −−>< xs:complexType name=”uss”>

< xs:sequence >< xs:element ref =”uids”/>< xs:element ref =” flags ”/>< xs:element name=”Extension” type=” tUSSExtension ” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence >< xs:attribute name=”id” use=” required ” type=” xs:string ”/>< xs:attribute name=”type” use=” required ” type=” xs:int ”/>

< xs:attribute name=”nafGroup” use=” optional ” type=” xs:string ”/></ xs:complexType>

<!−− User Public Identities for authentication −−>< xs:complexType name=”uids”>

< xs:sequence minOccurs=”1” maxOccurs=”unbounded”>< xs:element name=”uid” type=” xs:string ”/>< xs:element name=”Extension” type=” tExtension ” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence ></ xs:complexType>

<!−− GAA Application type specific Authorization flag codes −−>< xs:complexType name=”flags”>

< xs:sequence minOccurs=”0” maxOccurs=”unbounded”>< xs:element name=”flag” type=” xs:int ”/>< xs:element name=”Extension” type=” tExtension ” minOccurs=”0”/><xs:any namespace=”##other” processContents =”lax” minOccurs=”0” maxOccurs=”unbounded”/>

</ xs:sequence ></ xs:complexType>

</xs:schema>

The values are:

• The value of the attribute ”id” in the element ”guss” is the same as user’sIM Private Identity (IMPI) used in User-Name AVP.

• The value of the element ”timestamp” in the element ”guss” is the sametype as GUSS-Timstamp used in GUSS-Timestamp AVP and indicates thetimestamp of the GUSS. Timestamp value shall be expressed in UTC form,indicated by a time zone designator ”Z” immediately following the timeportion of the value.

• The value of the attribute ”id” in the element ”uss” is the same as serviceidentifier (GSID) used in GAA-Service-Identifier AVP.

120

• The value of the element ”uiccType” in the element ”bsfInfo” is:GBA to indicate the basic case, orGBA U to indicate that generation of Ks int NAF is also required in theBSF.The default value is GBA.

• The value of the element ”lifeTime” in the element ”bsfInfo” indicates a userspecific key lifetime (duration in seconds). If the lifeTime element is missingthe default value in the BSF is used.

• The value of attribute ”type” in the element ”uss” is GAA service type codedefined in annex B of [TS29.109].

• The value of attribute ”nafGroup” in the element ”uss” is an operator inter-nal group designator for a NAF group the USS is valid for. If this attributeis missing then only the attribute ”id” is used for selection of this element.

• Values of the element ”uid” are user’s public authentication identities fromthe HSS.

• Values of element ”flag” are user’s authorization flag codes from the HSSfor GAA service type indicated in the type attribute in the parent uss el-ement. If an authorization flag exist the NAF have permission to give thecorresponding service, otherwise not

• The value of the element ”keyChoice” in the element ”uss” is ”ME-based-key”, i.e., Ks NAF or Ks ext NAF shall be used, or ”UICC-based-key”, i.e.,Ks int NAF shall be used or ” ME-UICC-based-keys”, i.e., Ks ext NAF orKs int NAF can be used. The value of this attribute indicates to the NAF,which key shall be used. If the keyChoice attribute is missing, then as adefault the ”ME-based-key” shall be used by the NAF.

121

Appendix D GBA-UserSecSettings XML definition

122

Appendix E

Sample Configuration Files

In this Appendix chapter the configuration files used for the BSF, the NAF and theGBA Demonstration Client are given. The sample values are real values that havebeen tested and reflect the settings used to build a working GBA infrastructurefor the Fraunhofer FOKUS Open IMS Playground.

E.1 The BSF Configuration File

The BSF is configured using the bsf.properties file. Listing E.1 shows an exampleof how the BSF could be configured. This configuration is currently used in theFraunhofer FOKUS Open IMS Playground.

Listing E.1: A sample BSF Configuration File

############################################## bsfhost: specifies where tomcat listens , e .g. localhost , absinthe .open−ims.org# bsfport: specifies the port where tomcat listens# bsfdomain: specifies the bsf domain#############################################bsfhost=bsf.open−ims.orgbsfdomain=open−ims.orgbsfport=8080

############################################## useSecureBSF: set to ’ true ’ if BSF shall support TLS, you will then need to# provide a keystore file at the location defined below and a password# bsfTLSport: The BSF TLS (HTTPS) port# keystore: location of the keystore in BSF root folder

123

Appendix E Sample Configuration Files

# keystorePass: password for this keystore#############################################useSecureBSF=truebsfTLSport=8081keystore=/conf/.keystorekeystorePass=∗4Pas#

############################################## naf: specifies the target default NAF# nafport: specifies the port of the target NAF# nafdomain: specifies the target NAF should be set to the domain of the NAF.# nafid: specifies the target default NAFID#############################################naf=naf.open−ims.orgnafport=8090nafdomain=open−ims.orgnafid=primarynaf@fokus.fraunhofer.de

############################################## HSS: specifies the target HSS#############################################hss=absinthe.open−ims.orghssrealm=open−ims.org

E.2 The NAF Configuration File

The NAF is configured using the naf.properties file. Listing E.2 shows an exampleof how the NAF could be configured. This configuration is currently used in theFraunhofer FOKUS Open IMS Playground.

Listing E.2: A sample NAF Configuration File

############################################## host: specifies the host where tomcat listens# tomcatPort: the port where tomcat listens# domain: specifies the domain of the NAF# nafid: specifies the NAF−ID#############################################host=naf.open−ims.orgtomcatPort=8090

124

E.2 The NAF Configuration File

domain=open−ims.orgnafid=primarynaf@fokus.fraunhofer.de

############################################## NAF TLS Port: The NAF Secure Transport Layer port# keystore: The location of the Java Keystore to be used for certificate# storage . Should be set to the ’conf ’ directory in the NAF root directory# keystorePassword: The corresponding password for the Java keystore#############################################NAF TLS Port=8081keystrore =conf/.keystorekeystorePassword=∗4Pas#

############################################## virtualhosts: specifies the virtual host where tomcat listens# in addition to the host specified above#############################################virtualhosts =o2.open−ims.org o2fmcportal.open−ims.org pellmell.open−ims.org pellmell

.umts−at−fokus.de

############################################## This section specifies the application servers that are connected to the naf# example: o2=o2fmcportal.open−ims.org 8080# in this example the NAF listens for requests of the form# http:<virtualhost>:<port>\o2\<uri continues...># and redirects the request to# http://o2fmcportal.open−ims.org:8080\o2\<uri continues...># the application servers need to deploy applications in the specified location#############################################o2=193.175.134.200 8080o2forGBA=193.175.134.200 8080SmartMessenger=193.175.134.83 8080xdms=193.175.134.200 8888ejbca=10.147.65.128 8088

############################################## bsf: specifies the target non−secure BSF# bsfGBAserviceLocation: specifies the target BSF GBA service location#############################################bsf=bsf.open−ims.orgbsfGBAserviceLocation=http://bsf.open−ims.org:8080/bsf.gui

############################################## secureBSF: specifies the target secure BSF GBA service location

125

Appendix E Sample Configuration Files

# useSecureBSF: set to 1 if BSF supports TLS, set 0 if TLS is not supported by BSF#############################################secureBSF=https://bsf.open−ims.org:8081/bsf.guiuseSecureBSF=1

E.3 The GBA Demonstration Client ConfigurationFile

The client configuration file is named client.properties and is shown in listing E.3below:

Listing E.3: The Client Configuration File

# The BSF settingsHOST=bsf.open−ims.orgPORT=8080REQLINE=GET /bsf.servlet HTTP/1.1REQURI=/bsf.servletBSFREALM=open−ims.org

# The NAF settingsNAF=naf.open−ims.orgNAFport=8081NAFREQLINE=GET /ua/uaservlet HTTP/1.1NAFREQURI=/ua/uaservletNAFID=primarynaf@fokus.fraunhofer.de

# need to be set to ’ true ’ if target NAF employs TLSUSEsecureNAF=true

# only needed if USEsecureNAF=trueNAFtlsPORT=8081# only needed if USEsecureNAF=true. If this is set to true the client will accept

ALL server# certifactes . If set to false you will need to provide a Truststore .ACCEPTallNAFservers=true# only needed if ACCEPTallNAFservers=false. You need to set a Java Truststore (

keystore )# and the corresponding password.

126

E.3 The GBA Demonstration Client Configuration File

# The Truststore must contain the certifcates of trusted serversjavax .net . ssl . trustStore =C:/Dokumente und Einstellungen/Basti/.keystore# only needed if ACCEPTallNAFservers=false.javax .net . ssl . trustStorePassword=∗4Pas#

# The User settingsUSER=wahle@open−ims.orgde.fhg . fokus .milenage.SECRET KEY=wahlede.fhg . fokus . ims.PRIVATEID=wahle@open−ims.org

# The Milenage Algorithm settings, only modify if you know what you are doing!de.fhg . fokus .milenage.OPC=5dd771dfdfb3e1b8b76d62e16896aedcde.fhg . fokus .milenage.OP=00000000000000000000000000000000de.fhg . fokus .milenage.SQN=000000000001de.fhg . fokus .milenage.SQN RANGE=10000

The most essential settings are:

HOST The BSF host location. Can be an IP address or resolvable hostname.

PORT The BSF port.

REQLINE The BSF servlet location. This is the last piece of the complete requestURL. So in this example the entire request is GET bsf.open-ims.org:8080/bsf.servlet HTTP/1.1

NAF The NAF host location. Can be an IP address or resolvable hostname.

NAFport The NAF port.

NAFREQLINE The NAF servlet location.

USER This is the users IMPI as registered with the HSS.

de.fhg.fokus.milenage.SECRET KEY This is the secret shared with the HSS.

Milenage settings These settings are needed by the Milenage algorithm. Thereis usually no need to change them.

127

Appendix E Sample Configuration Files

E.4 The Diameter Peer Configuration File

A Diameter communication endpoint is referred to as a Diameter peer. TheDiameter peers are configured using the DiameterPeer.xml file. The followingsample configuration file contains configuration settings of the BSF Diameter peer.The NAF Diameter peer uses a very similar file. For the NAF, a target Diameterpeer would be the BSF (bsf.open-ims.org):

Listing E.4: Diameter Peer Configuration (BSF as Example)

<?xml version=”1.0” encoding=”UTF−8”?><DiameterPeer

FQDN=”bsf.open−ims.org”Realm=”open−ims.org”Vendor Id=”10415”Product Name=”JavaDiameterPeer”AcceptUnknownPeers=”1”DropUnknownOnDisconnect=”1”Tc=”15”Workers=”4”QueueLength=”32”>

<Peer FQDN=”naf.open−ims.org” Realm=”open−ims.org” port=”3869”/><Peer FQDN=”absinthe.open−ims.org” Realm=”open−ims.org” port=”3868”/><Acceptor port=”3868” /><Auth id=”16777216” vendor=”10415”/><Auth id=”16777216” vendor=”0” /><Acct id=”16777216” vendor=”0” />

</DiameterPeer>

A DiameterPeer represents a Diameter node which implements the Diameter pro-tocol and acts either as a Client or as a Server. The most important componentof a DiameterPeer is a PeerManager. The PeerManager manages a set of Peers.Each Peer has a Communicator, which maintains a Diameter connection. ThePeer is implemented based on the RFC 3588, section 5 and contains a state ma-chine defined in that part. Peers managed by the PeerManager can be configuredby a configuration file. They can also be detected and added to the PeerManagerin runtime dynamically.Since a DiameterPeer is listening to certain ports by using a set of Acceptors, theincoming Diameter Capabilities-Exchange-Request messages can be noticed. Uponreceiving such a request, a new Peer with a communicator will be created and added

128

E.5 The HTTP2IMS GW User Provisioning File

to the PeerManager.Outgoing Diameter messages and incoming Diameter messages are handled by theJavaDiameterPeer differently. For an outgoing Diameter request, JavaDiameter-Peer sends this message to the PeerManager directly. The PeerManager will findout a suitable Peer for sending it.An incoming Diameter message received by a communicator is pushed in a TaskQueueat first. This TaskQueue is a FIFO blocking queue. As soon as the message isavailable in the queue, a DiameterWorker will take it out of the queue and deliverit to a set of event listeners defined by the user.Typically, a Diameter client sends a Diameter message to a Diameter server di-rectly and receives a Diameter answer by adapting an EventListener. A Diameterserver, however, defines only an EventListener to process incoming Diameter re-quest.In order to provide a convenient way to handle Diameter request and answer atthe client side, a TransactionWorker is defined. A TransactionWorker groups arequest with its corresponding answer. By using TransactionWorker, a user needsnot to take care of mapping requests with answers. [wwwOpenIMS]

E.5 The HTTP2IMS GW User Provisioning File

Although the HTTP2IMS GW provides an interface for registering new users withthe gateway, the IMPI of the registered users need to be added by an adminis-trator. This might be automated in the future by adjusting the HSS. Listing E.5shows an example file of registered users:

Listing E.5: The User Provisioning

<?xml version=”1.0” encoding=”UTF−8”?><BSFuser>

<user><name>1</name><password>1</password><impi>testuser@open−ims.org</impi>

</user><user><name>wahle</name>

<password>wahle</password><impi>wahle@open−ims.org</impi>

</user><user>

129

Appendix E Sample Configuration Files

<name>weik</name><password>weik</password><impi>weik@open−ims.org</impi>

</user><user>

<name>horst</name><password>horst</password><impi>still to be set by admin</impi>

</user></BSFuser>

The last user element does not contain a valid IMPI yet. This occurs when a newuser has been registered via the HTTP2IMS GW but the IMPI still need to beprovisioned by an administrator.

130

Appendix F

Related Work and Patents

In this Appendix a short overview of related efforts in the field of the GenericAuthentication and Bootstrapping Architecture is given.In the field of USIM manufactures there are quite a few GBA related effortsunderway while there are considerably less GBA server side initiatives with publicvisibility.

Without naming concrete manufactures there a number of them that have research& development departments and laboratories where GBA-capable smart cards arecurrently developed.

As a larger project, this SPICE project can be named. The Service Platform forInnovative Communication Environment (SPICE) Project is an European IST-FP6 project, that has been launched in January 2006 in order to design, develop,evaluate and prototype an overlay service creation architecture and framework.It especially aims at enabling service delivery across multiple operator domains,networks and terminals. This includes the setup of a GBA. FOKUS is one of theSPICE partners. http://www.ist-spice.org/index.html

Furthermore, there are a number of GBA-related patents, such as: ”Method andapparatus for optimal transfer of data in a wireless communications system”United States Application 20060185003”An apparatus and method for sharing data in a communications system includea bootstrapping server function (BSF) configured to transmit a first message. Thefirst message includes a timestamp parameter corresponding to a generic boot-strapping architecture user security settings (GUSS) stored in the BSF. A homesubscriber server (HSS) is configured to receive the first message, to comparethe timestamp parameter corresponding to the GUSS stored in the BSF with atimestamp parameter corresponding to a GUSS stored in the HSS, and to trans-

131

Appendix F Related Work and Patents

mit a second message back to the BSF excluding the GUSS when the times-tamp parameters of the GUSS of the BSF and the HSS are equal.”[http://www.freepatentsonline.com/20060185003.html]

Please refer to the referenced URLs for other related patents. This is not anexhaustive list:

http://www.freepatentsonline.com/20060218396.htmlhttp://www.freshpatents.com/Method-apparatus-and-computer-program-

product-providing-bootstrapping-mechanism-selection-in-generic-bootstrapping-architecture–gba–dt20061214ptan20060282882.php

http://www.freepatentsonline.com/20060251257.html

132

Bibliography

[AccAuth] Maria Bonifati, Paolo De Lutiis, Corrado Moiso, Enrico Morello,and Laura Sarchi. Identity Federation for services in convergentnetworks. ICIN 2006, 2006.

[AIMS] Verizon Wireless, Cisco Systems, Lucent Technologies, Mo-torola, Nortel, and Qualcomm. Advances to IP Multimedia Sub-system (A-IMS) Architecture. June 2006.

[Cable29.109] PacketCable 2.0 IMS Delta Specifications Generic Authentica-tion Architecture (GAA); Zh and Zn Interfaces based on the Di-ameter protocol; Stage 3 Specification 3GPP TS 29.109. Cable-Labs, September 2006.

[Cable29.228] PacketCable 2.0 IMS Delta Specifications IP Multimedia (IM)Subsystem Cx and Dx Interfaces; Signalling Flows and MessageContents Specification 3GPP TS 29.228. CableLabs, September2006.

[Cable29.229] PacketCable 2.0 IMS Delta Specifications Cx/Dx Interfacesbased on the Diameter Protocol Specification 3GPP TS 29.229.CableLabs, September 2006.

[Cable33.220] Generic Authentication Architecture (GAA); Generic bootstrap-ping architecture Specification 3GPP TS 33.220. CableLabs,June 2006.

[camarillo] G. Camarillo and M. A. Garcıa-Martın. The 3G IP MultimediaSubsystem (IMS) Merging the Internet and the Cellular Worlds.John Wiley & Sons Ltd, 2 edition, 2006.

[CxA] All-IP Core Network Multimedia Domain - IP Multimedia Sub-system Cx Interface Signaling Flows and Message Contents.3GPP2, November 2005.

xvii

Bibliography

[CxB] All-IP Core Network Multimedia Domain - Cx Interface Basedon the Diameter Protocol; Protocol Details. 3GPP2, November2005.

[ETSI183033] Telecommunications and Internet converged Services and Pro-tocols for Advanced Networking (TISPAN); IP Multimedia; Di-ameter based protocol for the interfaces between the Call Ses-sion Control Function and the User Profile Server Function/-Subscription Locator Function; Signalling flows and protocol de-tails [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0,modified]. ETSI, April 2006.

[ETSI187003] Telecommunications and Internet converged Services and Proto-cols for Advanced Networking (TISPAN); NGN Security; Secu-rity Architecture. ETSI, March 2006.

[OMAap] XML Document Management (XDM) Specification. OMA,November 2006.

[OMAgba] OMA GBA Profile. OMA, December 2005.

[OMAxdm] XML Document Management Architecture. OMA, June 2006.

[RFC1945] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext TransferProtocol – HTTP/1.0. IETF, May 1996.

[RFC2246] T. Dierks and C. Allen. The TLS Protocol Version 1.0 . IETF,January 1999.

[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)Specification. IETF, December 1998.

[RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol –HTTP/1.1. IETF, June 1999.

[RFC2617] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach,et al. HTTP Authentication: Basic and Digest Access Authen-tication. IETF, June 1999.

[RFC3040] I. Cooper, I. Melve, and G. Tomlinson. Internet Web Replicationand Caching Taxonomy. IETF, January 2001.

xviii

[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Pe-terson, et al. SIP: Session Initiation Protocol. IETF, June 2002.

[RFC3310] A. Niemi, J. Arkko, and V. Torvinen. Hypertext Transfer Pro-tocol (HTTP) Digest Authentication Using Authentication andKey Agreement (AKA). IETF, September 2002.

[RFC3588] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko.Diameter Base Protocol. IETF, September 2003.

[RFC4346] T. Dierks and E. Rescorla. The Transport Layer Security (TLS)Protocol Version 1.1. IETF, April 2006.

[RFC791] J. Postel, editor. Internet Protocol. IETF, September 1981.

[S.S0109] Gabor Bajko, editor. Generic Bootstrapping Architecture (GBA)Framework. 3GPP2, March 2006.

[S.S0114] Yile Guo, editor. Security Mechanisms using GBA. 3GPP2,March 2006.

[Stallings] William Stallings. Data and Computer Communications, Sev-enth Edition. Pearson Prentice Hall, 2004.

[TS23.002] Technical Specification Group Services and Systems Aspects;Network architecture. 3GPP, March 2006.

[TS23.207] End-to-end Quality of Service (QoS) concept and architecture.3GPP, October 2005.

[TS24.109] Bootstrapping interface (Ub) and network application functioninterface (Ua); Protocol details. 3GPP, October 2006.

[TS29.109] Generic Authentication Architecture (GAA); Zh and Zn Inter-faces based on the Diameter protocol; Stage 3. 3GPP, October2006.

[TS29.228] 3rd Generation Partnership Project; Technical SpecificationGroup Core Network and Terminals; IP Multimedia (IM) Sub-system Cx and Dx interfaces; Signalling flows and message con-tents. 3GPP, September 2006.

xix

Bibliography

[TS29.229] Cx and Dx interfaces based on the Diameter protocol; Protocoldetails. 3GPP, June 2006.

[TS33.102] 3G security; Security architecture. 3GPP, January 2006.

[TS33.210] 3G security; Network Domain Security (NDS); IP network layersecurity. 3GPP, December 2006.

[TS33.220] Generic Authentication Architecture (GAA); Generic bootstrap-ping architecture. 3GPP, October 2006.

[TS33.221] 3rd Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; Generic Authentication Ar-chitecture (GAA); Support for subscriber certificates. 3GPP,March 2006.

[TS33.222] Generic Authentication Architecture (GAA); Access to networkapplication functions using Hypertext Transfer Protocol overTransport Layer Security (HTTPS). 3GPP, October 2006.

[TS33.223] 3rd Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; Generic Authentication Ar-chitecture (GAA); Generic Bootstrapping Architecture (GBA)Push Function (Release 7). 3GPP, August 2006.

[TS33.919] 3rd Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; 3G Security; Generic Au-thentication Architecture (GAA); System description. 3GPP,October 2006.

[TS33.920] 3rd Generation Partnership Project; Technical SpecificationGroup Services and System Aspects; SIM card based GenericBootstrapping Architecture (GBA) Early implementation feature(Release 7). 3GPP, June 2006.

[TS35.205] Specification of the MILENAGE algorithm set: An example algo-rithm set for the 3GPP authentication and key generation func-tions f1, f1*, f2, f3, f4, f5 and f5*; Document 1: General. 3GPP,January 2005.

[www3GPP] http://www.3gpp.org/. 3GPP, November 2006.

xx

[www3GPP2] http://www.3gpp2.org/. 3GPP2, November 2006.

[wwwCable] http://www.cablelabs.com/. CableLabs, November 2006.

[wwwEJBCA] EJBCA Online Documentation. PrimeKey Solutions, December2006.

[wwwOMA] http://www.openmobilealliance.org/. OMA, December 2006.

[wwwOpenIMS] http://www.openimscore.org/. Fraunhofer FOKUS Institute,November 2006.

[wwwTestbed] http://www.fokus.fraunhofer.de/ims/. Fraunhofer FOKUS,November 2006.

[wwwTISPAN] http://www.etsi.org/tispan/. ETSI/TISPAN, November 2006.

[wwwWikipedia] wikipedia.org. Wikimedia Foundation, Inc., November 2006.

xxi

Bibliography

xxii

Abbreviations and Glossary

3GPP The Third Generation Partnership Project was established in December1998 by the signing of the The 3rd Generation Partnership Project Agree-ment. It is a collaboration agreement that unifies telecommunications stan-dards bodies known as Organizational Partners. These Organizational Part-ners currently include ARIB, ETSI, CCSA, and others. In addition to theOrganizational Partners there are Market Representation Partners. 3GPPwas established to publish technical specifications.

3GPP2 Third Generation Partnership Project 2, a collaborative third generation(3G) telecommunications specifications-setting project comprising NorthAmerican and Asian interests developing global specifications for ANSI /TIA / EIA-41 Cellular Radiotelecommunication Intersystem Operations net-work evolution to 3G and global specifications for the radio transmissiontechnologies (RTTs) supported by ANSI / TIA / EIA-41. 3GPP2 was bornout of the ITU IMT-2000 initiative, covering high speed, broadband, andInternet Protocol (IP)-based mobile systems featuring network-to-networkinterconnection, feature/service transparency, global roaming and seamlessservices independent of location. [www3GPP2]

A-IMS Advances to IP Multimedia Subsystem

AAA Authentication, Authorization, Accounting. Used to configure services forproviding a secure network connection and records of user activity, by iden-tifying who the user is (→ authentication), what the user can access (→authorization), and what services and resources the user is currently con-suming (→ accounting).

AKA Authentication and Key Agreement, performs authentication and sessionkey distribution in Universal Mobile Telecommunications System (UMTS)networks. AKA is a challenge-response based mechanism that uses symmet-ric cryptography. AKA is typically run in a UMTS IM Services Identity

xxiii

Abbreviations and Glossary

Module (ISIM), which resides on a smart card like device that also providestamper resistant storage of shared secrets. [RFC3310]

AM Application Manager, A-IMS network element which is similar to the CallSession Control Functions (P-CSCF, S-CSCF, I-CSCF) and PSTN routing(BGCF-Breakout Gateway Control Function) defined in MMD/IMS. [AIMS]

ARIB Association of Radio Industries and Businesses, a standardization orga-nization in Japan. ARIB is designated as the center of promotion of theefficient use of the radio spectrum and designated frequency change supportagency. [wwwWikipedia]

AS Application Server, hosts the services/applications offered via an IMS infras-tructure.

ATIS Alliance for Telecommunications Industry Solutions

AUTN Authentication Token

AV Authentication Vector, generated by the HSS. Contains several security values(RAND, AUTN, XRES, CK, IK) used by the BSF to authenticate the UEand generate the key material Ks.

AVP Attribute Value Pair, represents an information element inside a Diametermessage.

B-TID Bootstrapping - Transaction Identifier, is used to bind the subscriber iden-tity to the keying material in reference points Ua, Ub and Zn. [TS33.220]

Base64 positional numeral system using a base of 64. It is the largest power of twobase that can be represented using only printable ASCII characters and isused as a transfer encoding. All well-known variants use the characters A-Z,a-z, and 0-9 in that order for the first 62 digits. The symbols chosen for thelast two digits vary considerably between different systems [wwwWikipedia]

BGCF Breakout Gateway Control Function

BIA BootstrappingInfo-Answer message, is the anwser to a BIR. Is a Diametermessage send over reference point Zn

xxiv

Abbreviations and Glossary

BIR BootstrappingInfo-Request message, is a Diameter message send over refer-ence point Zn

BM Bearer Manager, its main roles in A-IMS are policy enforcement point forQoS, accounting, Packet Flow Optimization (PFO), mobility and access poli-cies, security enforcement point, (including firewalls and intrusion detection)and as a mobility anchor point (Home Agent). [AIMS]

Bootstrapping Using 3GPP AKA infrastructure, the UE and the BSF generatejoint session keys. This key material can be used by the NAF (but this isnot part of the actual bootstrapping). [OMAgba]

Brute-force Attack A brute-force search is a trivial but very general problem-solving technique, that consists of systematically enumerating all possiblecandidates for the solution and checking whether each candidate satisfiesthe problem’s statement. In cryptanalysis, a brute force attack is a methodof defeating a cryptographic scheme by trying a large number of possibili-ties; for example, exhaustively working through all possible keys in order todecrypt a message. In most schemes, the theoretical possibility of a bruteforce attack is recognized, but it is set up in such a way that it would becomputationally infeasible to carry out. [wwwWikipedia]

BSF Bootstrapping Server Function, is hosted in a network element under thecontrol of an MNO. BSF, HSS, and UEs participate in GBA in which ashared secret is established between the network and a UE by running thebootstrapping procedure. The shared secret can be used between NAFs andUEs, for example, for authentication purposes. [TS33.220]

CA Certification Authority, issues certificates to, and vouches for the authenticityof entities. The level of trust you can assign to a CA is individual, per CA,and depends on the CAs policy and practices statement. [wwwEJBCA]

CCSA China Communications Standards Association

CK Confidentiality Key, part of the key material (Ks) bootstrapping on referencepoint Ub

Credentials Prove that you are who you claim to be. Very often the term creden-tials is used as synonym for username and password that have to entered inorder to gain access to some resource.

xxv

Abbreviations and Glossary

CS Circuit Switching, communication method where communication takes placevia a dedicated communication path through intermediate switching nodes.A setup phase and termination phase is needed and data is send as a con-tinuous stream of bits.

CSCF Call Session Control Function, is a SIP server that handles SIP-based trafficin IMS networks. CSCFs are central components of every IMS as theyprocess the SIP signaling. There are three forms of a CSCF (I-, S-, P-CSCF).

CSS Cascading Style Sheets, a stylesheet language used to describe the presenta-tion of a document written in a markup language. Its most common applica-tion is to style web pages written in HTML and XHTML, but the languagecan be applied to any kind of XML document, including SVG and XUL.The CSS specifications are maintained by the World Wide Web Consortium(W3C). [wwwWikipedia]

Diameter an Authentication, Authorization and Accounting (AAA) protocol.The name is related to the RADIUS protocol, which is the predecessor ofDiameter. As a diameter is twice the radius, the name Diameter was chosenfor this successor of the RADIUS protocol.

Dictionary attack is a technique in cryptanalysis and computer security for de-feating a cipher or authentication mechanism by trying to determine itsdecryption key or pass phrase by searching a large number of possibilities.In contrast with a brute force attack, where all possibilities are searchedthrough exhaustively, a dictionary attack only tries possibilities which aremost likely to succeed, typically derived from a list of words in a dictionary.Generally, dictionary attacks succeed because most people have a tendencyto choose passwords which are easy to remember, and typically choose wordstaken from their native language. [wwwWikipedia]

Digest A digest is a digital fingerprint of any kind of data. Another term fordigest is hash value. Hash values are generated by hash functions whichprovide a method of turning some kind of data into a hexadecimal notationwhich can then be handled by computers. A good hash function does notprovide the same number for different input data with a very high proba-bility. The digital fingerprint can then be called unique and servers as anunique identifier.

DNS Domain Name System, a system of servers that offer the distributed service

xxvi

Abbreviations and Glossary

of translating hostnames and Internet domain names into IP addresses.

DoS Denial of Service, usually used as the short form of an attack on a network.The attack is launched to crash the network by flooding it with lots of uselesstraffic.

EJBCA Enterprise Java Beans Certificate Authority

ETSI European Telecommunications Standards Institute, an independent, non-profit organization, whose mission is to produce telecommunications stan-dards for today and for the future. Based in Sophia Antipolis (France),the European Telecommunications Standards Institute is officially respon-sible for standardization of Information and Communication Technologieswithin Europe. These technologies include telecommunications, broadcast-ing and related areas such as intelligent transportation and medical electron-ics. ETSI unites 655 members from 59 countries inside and outside Europe.[http://www.etsi.org/]

FMC Fixed Mobile Convergence

FQDN Fully Qualified Domain Name

GAA Generic Authentication Architecture, ensures a secure and encrypted accessto IMS services. The GAA relies on certificates, authentication proxies andshared secrets. The GBA is part of the GAA.

GBA Generic Bootstrapping Architecture, used to bootstrap a short term securityassociation between a client and a server. This is done based on a long termsecurity association that is stored in a tamper resistant module in the clientas well as at the server side in a central network component such as a HSS.The tamper resistant device is usually represented by a UICC.

GBA H HTTP Digest Over TLS enhancements to the Generic BootstrappingArchitecture

GSID GAA-Service-Identifier

GSM Global System for Mobile Communications

xxvii

Abbreviations and Glossary

GUSS GBA User Security Settings, contains the BSF specific information elementand the set of all application-specific USSs. [TS33.220]

Hash Function A hash function (or hash algorithm) is a reproducible methodof turning data (usually a message or a file) into a number suitable to behandled by a computer. These functions provide a way of creating a smalldigital fingerprint from any kind of data. The function chops and mixes (i.e.,substitutes or transposes) the data to create the fingerprint, often called ahash value. The hash value is commonly represented in hexadecimal nota-tion. A good hash function is one that yields few hash collisions in expectedinput domains. In hash tables and data processing, collisions inhibit thedistinguishing of data, making records more costly to find. [wwwWikipedia]

HLR Home Location Register, central component of a GSM network which man-ages mobile subscribers. Contains complete subscriber profiles and informa-tion that allow incoming calls to be routed to the GSM subscriber.

HSS Home Subscriber Server, is in 3G IMS an evolution of the HLR in GSM. Itstores subscriber profile data, service and charging profile data, filter criteriaand corresponding service trigger point information. It can be seen as thecentral AAA data base within the IMS architecture. Is also a central com-ponent of the GBA and as such it stores security information like a sharedsecret (between User Equipment (UE) and HSS) and further authentica-tion and authorization information which can be used by the other GBAcomponents to grant or deny acess to services within an IMS network.

HTTP Hypertext Transfer Protocol, is a protocol that is used to transmit webpages over the Internet. It generally enables web browsing.

HTTP2IMS GW HTTP to IMS gateway, GBA component that allows non-GBAclients such as web browsers to make use of the GBA.

HTTPS TLS (Transport Layer Security) over HTTP

IANA Internet Assigned Numbers Authority, is broadly responsible for the al-location of globally-unique names and numbers that are used in Internetprotocols that are published as RFC documents. It maintains a close liaisonwith the IETF and RFC Editor in fulfilling this function. [wwwWikipedia]

IFC Initial Filter Criteria

xxviii

Abbreviations and Glossary

IK Integrity Key, part of the key material (Ks) bootstrapping on reference pointUb

IMPI IP Multimedia Private Identity

IMPU IP Multimedia Public identity

IMS IP Multimedia Subsystem

IP Internet Protocol, a data-oriented protocol for communicating data acrosspacket-switched networks. The Internet Protocol is designed for use in in-terconnected systems of packet-switched computer communication networks.The Internet protocol provides for transmitting blocks of data called data-grams from sources to destinations, where sources and destinations are hostsidentified by fixed length addresses. The Internet protocol also provides forfragmentation and reassembly of long datagrams, if necessary, for transmis-sion through small packet networks. [RFC791]

ISDN Integrated Services Digital Network, a standardized communication servicethat supports end-to-end digital transmission of voice, data, and signalingusing switching technology.

ISIM IP Multimedia Services Identity Module, an application running on a UICCsmart card in a 3G mobile telephone in the IP Multimedia Subsystem (IMS).It contains parameters for identifying and authenticating the user to theIMS. The ISIM application can co-exist with SIM and USIM on the sameUICC making it possible to use the same smartcard in both GSM networksand earlier releases of UMTS. The ISIM contains a private user identity, oneor more public user identities and a long-term secret used to authenticateand calculate cipher keys. [wwwWikipedia]

ISUP ISDN User Part, is part of the SS7 protocol. It defines procedures to setupand release trunk circuits carrying voice as well as data calls over the PSTN.

ITU International Telecommunication Union, headquartered in Geneva, Switzer-land is an international organization within the United Nations Systemwhere governments and the private sector coordinate global telecom net-works and services.[http://www.itu.int/home/index.html]

ITU-T The ITU Telecommunication Standardization Sector (ITU-T) coordinatesstandards for telecommunications on behalf of the International Telecom-munication Union (ITU). It was formed in 1993 to replace the International

xxix

Abbreviations and Glossary

Telegraph and Telephone Consultative Committee (CCITT, from the Frenchname Comite Consultatif International Telephonique et Telegraphique) andis based in Geneva, Switzerland. [wwwWikipedia]

Java EE Java Enterprise Edition, is a Java programming platform for develop-ing and running distributed multitier architecture Java applications, basedlargely on modular software components running on an application server.The Java EE platform is defined by a specification. Similar to other JavaCommunity Process specifications, Java EE is also considered informally tobe a standard because providers must agree to certain conformance require-ments in order to declare their products as Java EE compliant [wwwWikipedia]

KDF Key Derivation Function

Ks Key material, the security values that are bootstrapped via interface Ub andare used to secure refenrence point Ua.

Ks ext NAF ME-based key for a specific NAF

Ks int NAF UICC-based key for a specific NAF

Ks NAF NAF specific key material

LIF Location Interoperability Forum

MAA Multimedia-Auth-Anwser, the anwser to a MAR. Is a Diameter messagesend on interface Zh from HSS to BSF.

MAR Multimedia-Auth-Request, is a Diameter message send on interface Zh fromBSF to HSS.

MD5 Message-Digest algorithm 5, is a widely-used cryptographic hash function(see Glossary: hash function) with a 128-bit hash value. As an Internetstandard (RFC 1321), MD5 has been employed in a wide variety of secu-rity applications, and is also commonly used to check the integrity of files.[wwwWikipedia]

ME Mobile Equipment

xxx

Abbreviations and Glossary

MGCF Media Gateway Control Function

MGIF Mobile Gaming Interoperability Forum

MGW Media Gateway

MMD 3GPP2 Multimedia Domain

MMS-IOP Multimedia Messaging Interoperability Process

MNO Mobile Network Operator

MRFC Media Resource Function Control

MRFP Media Resource Function Processor

MVC Model-view-controller, is a design pattern used in software engineering. Incomplex computer applications that present lots of data to the user, one of-ten wishes to separate data (Model) and user interface (View) concerns, sothat changes to the user interface do not impact the data handling, and thatthe data can be reorganized without changing the user interface. The Model-View-Controller design pattern solves this problem by decoupling data accessand business logic from data presentation and user interaction, by introduc-ing an intermediate component: the Controller. [wwwWikipedia]

MWIF Mobile Wireless Internet Forum

NAF Network Application Function, is hosted in a network element. GBA may beused between NAFs and UEs for authentication purposes, and for securingthe communication path between the UE and the NAF. [TS33.220]

NASS Network Attachment Subsystem

nc nounce-count, a HTTP Digest protocol parameter

NGN Next Generation Networks

nonce number used once. Is a random value, used to protect against replayattacks. A HTTP Digest protocol parameter.

OASIS Organization for the Advancement of Structured Information Standards

xxxi

Abbreviations and Glossary

OCS Open Communication Server

OMA Open Mobile Alliance

OSI Model The Open Systems Interconnection Reference Model (OSI Model orOSI Reference Model) is a layered, abstract description for communicationsand computer network protocol design. It divides the protocol functions into7 layers. Each layer has the property that it only uses the functions of thelayer below, and only exports functionality to the layer above. So the OSImodel generally defines the requirements for communications between twocomputers and was conceived to allow interoperability across the variousplatforms offered by vendors. The model allows all network elements tooperate together, regardless of who built them. [wwwWikipedia]

PFO Packet Flow Optimization

PKI Public Key Infrastructure, an arrangement that provides for trusted thirdparty vetting of, and vouching for, user identities. It also allows binding ofpublic keys to users. This is usually carried out by software at a centrallocation together with other coordinated software at distributed locations.The public keys are typically in certificates. The term is used to mean boththe certificate authority and related arrangements. [wwwWikipedia]

PM Policy Manager, A-IMS builds upon the policy functions in MMD, strength-ening its role into the manager of the full set of services provided by theunderlying IP network. The PM provides unified management services ofnot just QoS and accounting, but also Packet Flow Optimization (PFO), mo-bility and access controls. The PM also links the conditions in the networkto the behavior of applications that run on the network. This allows theoperator to truly manage the way in which the network ultimately supportsthe applications it supports. To accommodate the realities of system migra-tion, the Policy Manager is flexible enough to implement device-specific orapplication-specific interfaces. [AIMS]

PS Packet Switching, message transmission method through a switched network,where long messages are divided into short packets.

PSK TLS pre-shared key TLS

PSTN Public Switched Telephone Network

xxxii

Abbreviations and Glossary

qop quality of protection, a HTTP Digest protocol parameter

QoS Quality of Service

RA Registration Authority, an administrative function that registers entities inthe PKI. The RA is trusted to identify and authenticate entities accordingto the CAs policy. There can be one or more RAs connected to each CA inthe PKI. [wwwEJBCA]

RAND Random challenge

REQ This indicates in Diameter headers that the message is a request.

RES Authentication Response

Reverse Proxy is a web server system that is capable of serving web pages sourcedfrom other web servers, making these pages look like they originated at thereverse proxy. [TS33.222]

RootCA Root Certification Authority, has a self-signed certificate and is alsocalled Trusted Root. Verification of other certificates in the PKI ends withthe RootCAs self-signed certificate. Since the RootCAs certificate is self-signed it must somehow be configured as a trusted root with all clients inthe PKI. [wwwEJBCA]

SDM Services Data Manager, similar to an HSS (Home Subscriber Server), andis capable of being the data repository for both SIP and non-SIP services inA-IMS. The SDM is also the recipient of accounting data from the variouselements. [AIMS]

SDO Standards Development Organization

Service enabler technology to be used in the development, deployment or op-eration of a service, so as to enable the service. It is usually defined in aspecification, or a set of specifications. Such service enabler specificationsare for example published by the Open Mobile Alliance (OMA). Examplesof service enablers are: presence enhanced communication, location services,and group management.

SIM Subscriber Identity Module, is a smart card that securely stores the key

xxxiii

Abbreviations and Glossary

identifying a mobile phone service subscriber, as well as subscription in-formation, saved telephone numbers, preferences, text messages and otherinformation. The equivalent of a SIM in UMTS is a Universal SubscriberIdentity Module (USIM). [wwwWikipedia]

SIP Session Initiation Protocol, an application-layer control (signaling) protocolfor creating, modifying, and terminating sessions with one or more partici-pants. These sessions include Internet telephone calls, multimedia distribu-tion, and multimedia conferences. [RFC3261]

SM Security Manager, in A-IMS it provides a cockpit for the network, monitoringall network activity and performing correlation and computations of base-line usage. The Security Manager detects anomalies based on programmedalgorithms, and then controls network elements to respond to threats. It isthe heart of the Security Operations Center (SOC), the parallel of the NOC(Network Operations Center) but for security. [AIMS]

SOC Security Operations Center

SPAN Services and Protocols for Advanced Networks

SSO Single Sign-On, minimizes the necessity for an end user to provide creden-tials, without compromising security.

STP Service Trigger Point

TIA Telecommunications Industry Association

TIPHON Internet Protocol Harmonization Over Networks

TISPAN Telecoms & Internet converged Services & Protocols for Advanced Net-works

TLS Transport Layer Security. The Transport Layer Security protocol providescommunications security over the Internet. The protocol allows client/serverapplications to communicate in a way that is designed to prevent eavesdrop-ping,tampering, or message forgery. [RFC4346]

TTA Telecommunications Technology Association

TTC Telecommunication Technology Committee

xxxiv

Abbreviations and Glossary

Ua UE-NAF interface for GAA applications

Ub UE-BSF interface for bootstrapping

UE User Equipment

UICC Universal Integrated Circuit Card, is the chip card used in mobile terminalsin GSM and UMTS networks. The UICC ensures the integrity and securityof all kinds of personal data, and it typically holds a few hundred kilobytes.[wwwWikipedia]

UMTS Universal Mobile Telecommunications System. One of the third-generation(3G) mobile phone technologies which is standardized by the 3GPP, and isthe European/Japanese answer to the ITU IMT-2000 requirements for 3GCellular radio systems. [wwwWikipedia]

URI Uniform Resource Identifier

URN Uniform Resource Name

USIM Universal Subscriber Identity Module, an application for UMTS mobiletelephony running on a UICC (see UICC) smart card which is inserted ina 3G mobile phone. It stores user subscriber information, authenticationinformation and provides storage space for text messages. For authenticationpurposes, the USIM stores a long-term preshared secret key, which is sharedwith the Authentication Center in the network. [wwwWikipedia]

USS User Security Setting, is an application and subscriber specific parameterset that defines two parts, an authentication part, which contains the list ofidentities of the user needed for the application (e.g. IMPUs, pseudonyms),and an authorization part, which contains the user permission flags (e.g.access to application allowed, type of certificates which may be issued). TheUSS is delivered to the BSF as a part of GUSS from the HSS, and from theBSF to the NAF if requested by the NAF. [TS33.220]

Ut 3GPP reference point for UE - AS interconnection

Virtual host is a host that can be accessed with different DNS names.

W3C World Wide Web Consortium

xxxv

Abbreviations and Glossary

XCAP XML Configuration Access Protocol, allows access and manipulation (cre-ation, changing, deletion, etc.) of well-structured XML documents residingon a XDMS.

XDM XML Document Management

XDMC XML Document Management Client, is an entity that provides access tothe various XDMS features. It can be implemented in both terminal andserver entities. To access XML documents on a XDMS, usually, a XDMCis implemented in the UE, which contacts a so-called Aggregation Proxy,which is the contact point for all XDMCs.

XDMS XML Document Management Server, provides storage for XML docu-ments. The documents are usually accessed and changed via XCAP.

XML Extensible Markup Language, is a meta-language for describing data usingself defined tags.

XRES Expected authentication response

Zh BSF-HSS interface for bootstrapping procedure

Zn BSF-NAF interface for GAA applications

xxxvi