• No se han encontrado resultados

Propuesta de valor

3.1. Descripción del producto

3.1.2. Propuesta de valor

As outlined in the previous chapter, TISPAN works on an IMS-centric approach for both wireless and wireline networks. This access independent IMS is intended to 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

with a smart card (UICC) which holds the relevant security values and applica- tions in order to guarantee both network and service authentication (ISIM). This assumption does not hold true when is comes to xDSL terminals. As depicted by figure 2.6 on page27, on the lowest layer authentication is realized based on Net- work Attachment Subsystem (NASS) credentials. The NASS provides registration at access level which involves the access authentication run between the UE and the NASS. While this is very secure on the access level, it is useless on higher layers as this type of authentication authenticates a piece of hardware rather a specific user (user identity). A straightforward example might be a family-shared xDSL line where the access credentials tend to be saved in the DSL modem, which usually also serves as a router to supply several family home PCs with Internet access. In this setup the access level credentials can hardly be used for IMS level or service level authentication because they identify the DSL modem/router rather than the concrete user that is accessing services. Service layer authentication must be carried out based on the user identity. This is why it is difficult to reuse the access 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 readers can 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 have several IMPUs that are all mapped to the same IMPI.

Please refer to figure 2.6 on page 27again and note that on the IMS access layer, as well as on the service layer, an ISIM is necessary. The IP Multimedia Services Identity Module (ISIM) is an application that is running on the UICC smart card in 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-term secret used for authentication purposes and calculation of cipher keys. The prob- lem that arises from the infrastructure shown be figure 2.6is obvious: how should the UICC, that is usually inserted in a 3G mobile phone, be used on a xDSL terminal (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 read

UICC cards. For computers that do not dispose of a smart card reader, there are USB smart card reader sticks available, as for example shown in figure

4.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 would enable IMS authentication from a xDSL terminal as the relevant security parameters can be read from the card and can be used on an application running IMS authentication with the IMS network. Of course this can be repeated on the service level. Thus, to enable IMS/service layer authen-

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

tication the terminal need to be equipped with a card reader and certain applications that are able to extract the relevant information from the card and use the latter on authentication protocol runs. In 3G network devices both functions (card reader + authentication application) are provided by the 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 via bluetooth. The phone would also need to be prepared to accept this kind of security data transmission. The main concerns about this approach are security issues. During the last 3 years, bluetooth users faced different kind of bluetooth attacks which enabled the attacker to extract information from a target device without the consens of the victim. Keeping this in mind, the blutooth connection alternative is probably the least favorable one. Of course the connection between telephone and PC can also be established via a cable, which draws less security concerns, but reduces easy, plug and play use.

Login page Yet another alternative to enable IMS/service layer authentication while using a xDSL terminal is introduced in the following. This approach has been realized as part of this thesis implementation. The idea is rather simple. 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.

The authentication functionality has been moved to a website presenting a 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. The login 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 at the HTTP2IMS GW which runs the security protocols with the BSF and assumes 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 GBA infrastructure from his PC at home, public terminals, or wherever without the need of his UICC/ISIM.

Another possibility is to additionally require the user to use its mobile phone to run the standard GBA procedures with the BSF before providing the credentials at the login page / HTTP2IMS GW. This would increased the overall 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 which could be used to access the IMS services directly, but the user wants to use its PC because of larger display, keyboard, etc.

This HTTP2IMS GW approach solves the problem that a UICC/ISIM is needed while surfing via PC. The solution will be discussed in greater detail in section 4.2.7.

It need to be mentioned however, that this concepts to some extend breaks the 3GPP security architecture as the UICC/hardware-based security mech- anisms are replaced by a password-based login procedure. The HTTP2IMS GW solution outlined above is threatened by activities such as Phishing and Pharming that threaten all web sites and Internet portals. This need to be taken into account when deploying such a solution.