Segmentación de mercado objetivo

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 BSF HTTP2IMSGW Ub* HTTP2IMSGW + BSF Ub*

Figure 4.5: The Ub* Interface

Any client that has an up to date Internet browser installed can make use of the 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_{. The}

HTTP2IMS GW displays a web page that has the Fraunhofer Open IMS Play- gound layout. Existing Cascading Style Sheets (CSS) have been used to give the site a layout similar to yet existing Playground service pages. Figure 4.6 shows a screenshot 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 figure4.6. The login username and password can be set by the user. The password must contain a minimum of 10 characters including a least one normal and one capitalized letter a number and a special character in order to assure a certain level of protection against brute-force and dictionary attacks. Additionally, the login page increas- ingly delays communication every time a key is falsely introduced. If a key is falsely 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 falsely entered passwords within the last four minutes, the user has to wait five seconds

11_{http://www.mozilla-europe.org/en/} 12

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 dictionary attacks unlikely as the delay will increase infinitely. The rate of delay increase can also 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 password for the entered user name) the HTTP2IMS GW obtains AVs and GUSS via the BSF for the IMPI (obtained for the entered username). The AVs and GUSS are stored at the BSF. The HTTP2IMSGW writes two cookies to the browser. The cookies 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 to have HTTP2IMS GWs in a domain different from the domain of the BSF. The Ub interface could additionally be secured by IPSec, TLS, or another security mechanism that would make the Ub connection between HTTP2IMS GW and BSF oven an untrusted network more secure. This however is not necessary as in HTTP Digest AKA, the password is never transmitted over the communication channel.

The HTTP2IMS GW implementation of this thesis makes use of case b) of figure

4.5. BSF and gateway have realized in a single server component. This has the advantage that there is no need to run Ub logic between the HTTP2IMSGW and the BSF which leads to increased communication speed.

The HSS-obtained GUSS contain one or more user identifier (UID). The UID is known to the ASs and used as the username at the ASs. The user therefore need to have a choice of which UID to use when accessing an AS. This has been realized at the HTTP2IMS GW as a list of UIDs (extracted from the GUSS received from the HSS for a certain IMPI). The user sees which UIDs have been registered and are ready to be used with different services. Currently all services can be used with all UIDs. An idea for further specification efforts or a proprietary solution might be to distinguish between different services based on the UID. Some services might only be 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:[email protected] and sip:[email protected]. Beneath each UID, the available services are listed. In figure 4.7 there are currently three

different services supported: the O2 Portal, the Smart Messenger service, and a certificate enrollment service (two web browsers are supported, Firefox/Mozilla and Internet Explorer).

To sum up, the Ub* approach replaces the 3GPP AKA mechanism between BSF and UE by a simple login procedure. This has clear advantages but also some drawbacks. The advantage is that the central data and identity store - the HSS - remains the central network component in terms of data storage even when using GBA with standard Internet browsers. The disadvantage is that the username / password based login procedure is less secure than the AKA mechanism. Another disadvantage is that the HTTP2IMS GW needs to maintain a list of registered users. 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 at the 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 the HTTP2IMS GW user store. This remains an open issue for further research and implementation 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 cookie must be a common domain cookie, as explained in section 4.1.3), the latter can provide service access for various applications hosted by one or more application servers.