The XDM architecture has been introduced in section3.6and is depicted by figure
3.11. It has been outlined how the documents that are stored on a XDMS can be accessed and changed (using XCAP).
Fraunhofer FOKUS has developed the FOKUS XDMS which also implements an Aggregation Proxy. In this validation setup it has been tried to obtain a contact list (well-structured XML document residing on the FOKUS XDMS that contains the 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
3
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 of the OMA XDM infrastructure and the 3GPP GBA. The validation scenario starts with editing the contact list of the user [email protected]. This is done using a SIP softphone such as Eyebeam 4. The list is edited and stored on the XDMS. It is 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 and the AP by applying the Bootstrapping Procedure and extended GBA mechanisms as 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 the request by the AP.
Figure 5.8 shows the HTTP request from the AP to the XDMS. Note that the X-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 [email protected] in a HTTP 200 OK response. The list is a XML document that is carried in the body of the response. The list can now be displayed in the browser or can be downloaded to a desired location. Figure5.9 shows the decoded packet flow of the request and the corresponding response.
The described validation scenario has been tested successfully.
4
Figure 5.9: The Decoded HTTP GET and 200 OK Response Flow
This chapter provided a clear view of how the implementation has been validated within the FOKUS Open IMS Playground showing several screenshots and packet flow traces.
The last chapter will summarize this thesis and describe some topics that can be addressed by future efforts.
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 a Generic Bootstrapping Architecture. After outlining what the IMS is and describ- ing its role as vital part of the ETSI TISPAN specified Next Generation Network architecture, the thesis explained the core IMS network elements and its general structure. Furthermore, it gave insights into the relevant standardization organi- zations and the published specifications related to the GBA. In a clear and concise manner, this thesis has described the design of the actual implementation and its practical realization and also gave details on its validation within the Fraunhofer FOKUS Open IMS Playground.
The design and implementation of the GBA on the one hand closely follows the relevant specifications and implements the specified GBA infrastructure and a GBA client. On the other hand it enhances the specified GBA infrastructure by introducing a HTTP to IMS gateway (HTTP2IMS GW) which enables non-GBA- capable clients such as standard web browsers to use the services secured by the GBA network elements. It has been outlined that this approach is confronted with 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 know if this will be the infrastructure of choice for future telecommunication systems. Fraunhofer FOKUS has positioned itself very well running a unique IMS testbed for the benefit of academic and industry initiatives. This thesis has contributed to the testbed by defining and implementing a service layer access authentication infrastructure, that is based on specifications spanning multiple standardization organizations.
The industry is in need for academic efforts in this area, which is proven by the fact that some of this thesis’s implementation results have already been sold, thanks
to some promotion by my supervisors, as a prototype implementation to a major industry player.
Future efforts certainly need to be undertaken in the client area. Currently, there are no commercial IMS clients publicly available that fully support the Generic Bootstrapping Architecture.
With regard to this thesis’s implementation, future work should concentrate on the diversity of different authentication methods (or GBA profiles) that can be used with this GBA implementation. HTTP Digest authentication should also be supported on the Ub interface which means porting the NAF HTTP Digest implementation to the BSF. On the Zh interface however, this requires adapta- tions to the HSS. The FHoSS is currently being adapted to support HTTP Digest authentication.
On the Ua interface, the NAF should also support pre-shared key TLS as well as the certificate-based authentication of clients as additional authentication meth- ods. With the PKI Portal functionality, the NAF/AP can already issue subscriber certificates. 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 possible application 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 secure storage. This could be done using a mobile phone (the GBA client runs on the device) 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 concepts for Federated Identity Management, Web Services and Cross Domain Single Sign- On. In Release 7, the 3GPP GBA is specified with Web Services support and interworking with the Liberty Alliance. By integration of Liberty Identity and Service 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 mobile converged services and the merger of paradigms.
German Summary
Im Folgenden, wie vom Pr¨ufungsausschuss gefordert, eine deutsche Zusammenfas- sung der vorliegenden Diplomarbeit. Das Thema der Arbeit lautet ¨ubersetzt: ”Entwurf und Implementierung einer HTTP-basierten Authentifizierungsinfra- struktur f¨ur IP Multimedia Subsystem Dienstzugang”. Wie der Titel erkennen l¨asst, ist neben der theoretischen Betrachtung der Sachverhalte, eine praktische Implementierung 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 f¨ur Nord Amerika und Asien ver¨offentlicht. IMS stellt außerdem die Basis f¨ur den Next Generation Network Release 1 dar, der von ETSI TISPAN (European Telecommunications Standards Institute Telecoms and Internet converged Services and Protocols for Advanced Networks) spezifiziert wurde.
Das Fraunhofer FOKUS Institut verf¨ugt ¨uber ein eigenes IMS Testlabor, den FOKUS Open IMS Playground. Das Labor stellt ein komplettes IMS System zu Verf¨ugung, das aus Eigenentwicklungen und Partnerkomponenten aufgebaut wurde und zu Forschungszwecken und f¨ur Industrieprojekte genutzt wird. Neben SIP (Session Initiation Protokoll), kann im IMS das Hypertext Transfer Protocol (HTTP) eingesetzt werden, um Dienste zur Verf¨ugung zu stellen. Viele SIP- basierte Dienste stellen außerdem Konfigurationswebseiten zur Verf¨ugung, um Personalisierung zu erm¨oglichen und generelle Einstellungen vorzunehmen. Auf diese Seiten kann mit HTTP zugegriffen werden.
Das Ziel der vorliegenden Arbeit ist es, eine Infrastruktur zu beschreiben und zu implementieren, die Authentifizierung und Autorisierung von Nutzern, die auf genannte HTTP-basierte Dienste zugreifen m¨ochten, sicherzustellen. Es wird dazu die bei 3GPP/ 3GPP2 und ETSI TISPAN verwandte Generic Bootstrap-
ping Architecture (GBA) umgesetzt, die es erm¨oglicht, dynamisch Schl¨usselpaare f¨ur eine sichere HTTP Verbindung zwischen Server und Nutzer auszuhandeln. Die Schl¨usselpaare k¨onnen dann nachfolgend verwand werden, um den Nutzer gegen¨uber Diensten zu authentifizieren und den Nachrichtenaustausch zu ver- schl¨usseln.
Die Arbeit folgt einer klaren Struktur. Zu Beginn werden das IMS und seine Vorteile f¨ur die Betreiber, als auch die Nutzer vorgestellt. Es folgt eine ausf¨uhrliche Beschreibung der relevanten Standardisierungsorganisationen, sowie der von diesen ver¨offentlichten Spezifikationen, die f¨ur die Arbeit von Bedeutung sind. Es wird dann der Entwurf der Implementierung dargelegt, sowie die praktische Umsetzung beschrieben. Den Abschluss der Arbeit bildet ein Validierungskapitel, in welchem die 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 dazugeh¨origen Dokumentation, an einen der f¨uhrenden Telekommunikationsanbieter als Prototypenentwicklung verkauft.
Diameter Commands
This Appendix describes the Diameter Commands used by BSF and NAF on the interfaces 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 format of Multimedia-Auth-Request (MAR) message. The content of the message is given below in the same format as in 3GPP TS 29.229. The curly brackets indicate mandatory 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 10415 0∗1 {Auth− Application −Id} ; 16777221 0∗1 {Acct− Application −Id} ; Omitted
B.2 Multimedia-Auth-Answer (MAA)
The HSS shall send the following Bootstrapping-Answer message in the format of Multimedia-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. The content 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 10415 0∗1 {Auth− Application −Id} ; 16777220 0∗1 {Acct− Application −Id} ; Omitted
The Destination-Realm AVP is set to the subscriber’s BSF. The address of the BSF is extracted from the B-TID.
The NAF indicates the GAA services for which the information is retrieved by GAA-Service-Identifier AVPs. The Bootstrapping Transaction Identifier defines the 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 or Ks ext NAF) is sent in the ME-Key-Material AVP. The common key material with the UICC (Ks int NAF) is optionally sent in the UICC-Key-Material AVP only 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 represented according the Diameter Time data format in seconds that have passed since 0h on 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 instead of 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, 1900 00: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-
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.
Specification of the Key Derivation
Procedure
This normative definition of the key derivation function and NAF specific keys has been taken from [TS33.220].
C.1 Introduction
This annex specifies the key derivation function (KDF) that is used in the NAF specific 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 - not bit strings of arbitrary length:
2. a single input parameter will have lengths no greater than 65535 octets.