The GBA is part of the GAA (Generic Authentication Architecture) which en- sures a secure and encrypted access to IMS services on the service layer (see 2.1). The GAA relies on certificates, authentication proxies and shared secrets.
The GBA implementation of this thesis covers authentication by means of shared secrets and implements an authentication proxy in order to serve all applications that share a need for authentication and authorization of a client (the user equip- ment) before further communication can take place with the connected Applica- tion Server. Figure2.3shows the GBA architecture and how it fits into the overall IMS architecture. The GBA consists mainly of two new elements: the Bootstrap- ping Server Function (BSF) and the Network Application Function (NAF). UE in figure 2.3 stands for User Equipment, HSS and AS have already been intro- duced in the previous section. Before going into detail how the GBA works and
Ub Ua Zh Zn HSS AS UE BSF NAF
Figure 2.3: The Generic Bootstrapping Architecture
which reference points have been defined, I want to raise a few more words on the layered architecture of NGNs and how the GBA fits into this approach. As previously described, the vertical structure of NGNs consists of three layers. The access layer, the session control layer and the service layer. The concept of GBA - simplifying service access - with its elements BSF and NAF is located in the service layer. Please have a look at figure 2.4.
Figure 2.4 reuses and merges figure 2.2 and figure 2.3 to demonstrate the lay-
Ub Ua Zh Zn BSF NAF HSS P-CSCF S-CSCF I-CSCF UE Application Server
Media Server / Media Gateway / Signaling Gateway Access Network Legacy Networks (GSM, PSTN) P-CSCF Cx Mw Mw Mw Mw Mw Cx ISC Sh Mi Gm Service Access Session Control Access Networks
Figure 2.4: The GBA and IMS Architecture Interpreted as NGN Layers
ered NGN architecture. It is important to note, that this figure demonstrates the concept, rather than trying to allocate network elements to concrete layers. This
means that the overall IMS architecture with CSCFs et cetera - being a session control system - is located in the session control layer. Following this logic con- sequently, the GBA - being a service access supporting system - is located in the service layer. In order to avoid network components to be depicted twice (like HSS, AS, and UE) the connectors span multiple layers. This implies that the GBA part of figure 2.4 (service layer) can itself be split into different layers, but taken as a general concept, it should be placed in the service layer.
In the following, the GBA entities will be described as depicted by figure 2.3. Especially the two introduced elements BSF and NAF need to be explained as well as the interworking of these components with the existing elements such as HSS and AS:
BSF The Bootstrapping Server Function (BSF) has three interfaces: Ub, Zn and Zh. It is publicly reachable from the Internet on the Ub interface, whereas the interfaces Zn and Zh are only accessible from within the operators net- work. The BSF can also be configured to accept requests from outside of the operators network on the Zn interface, but at this stage the BSF shall be assumed to communicate with NAFs from within the operators network only.
On the Ub interface the BSF acts as a Hypertext Transfer Protocol (HTTP) server. The BSF can optionally be configured to support HTTPS (Trans- port Layer Security (TLS) over HTTP) on the Ub interface.
The interfaces Zh and Zn are Diameter interfaces. On the Zh interface the BSF communicates with the HSS, whereas on the Zn interface it is listen- ing for Diameter requests from the NAF. The BSF therefore also acts as a Diameter server.
NAF The Network Application Function (NAF) has two interfaces: Ua and Zn. On the Ua interface it listens for HTTP/HTTPS requests and therefore acts as a HTTP/S server. On the Zn interface it communicates with the BSF exchanging Diameter messages. The connection with the AS is also a HTTP connection. Optionally this connection can be secured. This also depends on the location of the AS. At this stage it shall be assumed that the AS is located within the operators network and is not publicly reachable from the Internet. Therefore no further security measures are necessary on this interface. If the connection has to established via untrusted networks, confidentiality and integrity protection can be provided using NDS/IP mechanisms as specified in [TS33.210]. Because the AP terminates the TLS tunnel from UE, it is also possible to establish a TLS tunnel with ASs.
with the GBA infrastructure. It has already been authenticated on the ac- cess layer (depending on the technology used to establish a connection) at the time of the first request to the GBA infrastructure components. It might also have been authenticated on the session control layer (IMS authentica- tion). The UE can then proceed to authenticate with the GBA in order to access the services offered by the AS. How this occurs will be discussed in the following.
In the setup for this thesis it will be assumed that the HSS and the ASs reside within the operators network and cannot be reached from the Internet. The BSF and NAF have public HTTP/S interfaces in order to communicate with the UE. There are also ASs that have public interface but they must then apply their own security measures on these interfaces.
It will now be described in detail how the GBA works and which messages are exchanged. Note that the following chapters also provide detailed information on the bootstrapping procedure. The following first description is given to introduce the general (simplified) concept, which will be further detailed and modified ac- cording to the different standardization organizations.
Figure 2.5 shows a sequence chart of the very general bootstrapping procedure.
UE BSF HSS NAF 1. GET 2. Redirect 3. GET 6. 401, Nonce 7. GET, RES 4. Get Vectors 5. Vectors 9. 200 OK 10. GET 11. Get GUSS 8. if RES = XRES 12. GUSS 13. 200 OK
1. GET: this is a HTTP GET transfered over interface Ua. In this first step the user requests a web page residing on an AS, which is hidden behind the NAF. The NAF acts as a reverse proxy. This means that requests targeting an AS will be directed to the NAF due to DNS and network configuration. An example: The user enters http://service.open-ims. org/servicein his web browser in order to access his favorite service. Due to DNS configuration service.open-ims.org will be resolved to the IP address of the NAF. The browser is therefore sending the request to the NAF. This is why the sequence chart shows no application servers. Until the user has actually been authenticated, there is no contact with any AS. 2. Redirect: Upon receiving the request from step 1, the NAF checks if the user
has already been authenticated. This is done by checking for cookies (that should previously have been set by the NAF if the user has already been authenticated) and checking for special HTTP headers, that would have been set by a GBA-capable client in order to demonstrate that successful authentication has already taken place. If authentication has not taken place yet, the NAF redirects the client to the BSF, where the bootstrapping procedure begins.
3. GET: The client accesses the BSF following the redirect by the NAF. This is interface Ub communication. Note that this step actually consists of of two other steps. The user first accesses the BSF which denies further communication, if there is no HTTP header carrying some user identifier. The client then accesses the BSF providing a user identifier.
4. Get Vectors: In this step the BSF requests Authentication Vectors (AV) from the HSS over reference point Zh for the user identifier that has been obtained from the client in the previous step. This is Diameter communication. The Diameter protocol itself and the exchanged messages will be discussed in a later section. The Authentication Vectors consist of a nonce (number used once) value, a respected response value XRES and further security values. Additionally, Generic User Security Settings (GUSS) are transfered from the HSS to the BSF. The GUSS carry user identities that are recognized at the AS, and authorization values, which can be transfered to the NAF. The NAF can decide - based on the GUSS data - if a user is authorized to use a certain type of service.
However, at this stage the BSF requests the Authentication Vectors which are needed to challenge the client and proceed with the authentication. 5. Vectors: The HSS returns the Authentication Vectors for that user. This
client response digest against a digest of the XRES value in step 8.
A digest is a digital fingerprint of any kind of data. Another term for digest is hash value. Hash values are generated by hash functions which provide a method of turning some kind of data into a hexadecimal notation which can then be handled by computers. A good hash function does not provide the same number for different input data with a very high probability. The digital fingerprint can then be called unique and servers as an unique iden- tifier.
The authentication vectors furthermore contain parts of the key material that is used to secure the communication between the client and the NAF. 6. 401, Nonce: The BSF determines that the client has not yet been authen-
ticated and challenges the client with the nonce value. From this value the client need to be able to generate the response RES by applying the IMS Authentication and Key Agreement (AKA) schema [TS33.102], [TS35.205]. The client can also authenticate the server as AKA provides mutual authen- tication.
7. GET RES: The client calculates the value RES with the given nonce from the BSF. The RES is only identical to the expected XRES if the client is in possession of the nonce and the secret shared between the client and the HSS (the secret need to be agreed during IMS contract establishment). For a detailed description of the algorithm by which the RES is calculated please refer to [TS33.102] and [TS35.205]. A digest of the calculated value RES is send to the BSF.
The client furthermore calculates the key material Ks NAF used for reference point Ua security mechanisms.
8. if RES = XRES: The BSF verifies that the client calculated digest of the value RES matches the digest of the expected response XRES and that the client must therefore be in possession of the correct secret key. Note that by using this security mechanism, the secret (which is only known by HSS and UE and which is even unknown to the BSF) is never actually transfered over the potentially insecure communication path.
If the values are identical, the client is allowed further communication with BSF and NAF. In case of failure, a HTTP 401 Unauthorized (carrying the nonce in a special HTTP header) is send to the client.
9. 200 OK: This HTTP 200 OK message indicates the successful authentication. The client is now being redirected to the NAF. Note that this thesis covers different approaches of how successful authentication is demonstrated to the NAF. This can be done by setting special HTTP headers (this requires a
special IMS GBA client as standard browsers do not support this) or setting cookies on the client machine. The cookie approach has the advantage that it works with standard browsers and no client side adaptations are necessary. This thesis will introduce a mechanism to carry out the GBA procedures with a standard browser in section 3.4.
10. GET: The client follows the redirection back to the NAF. It now needs to demonstrate to the NAF that is has successfully authenticated with the BSF. This can be done by applying the HTTP Digest mechanism [RFC2617] or the NAF can check for cookies. More details on this in the following chapters. 11. Get GUSS: The NAF obtains the key material and GUSS from the BSF over
reference point Zn. This is Diameter communication.
12. GUSS: The BSF returns the GUSS and key material used to secure reference point Ua.
13. 200 OK: The client is allowed to access the AS through the NAF. The NAF acts as a reverse proxy and all requests between client and AS go through the NAF. This enables service developers to forget about authentication and channel security. The NAF (with support from the BSF) handles au- thentication, authorization, and channel security and relives the connected applications from these tasks by acting as a reverse proxy providing SSO. The authentication and reverse proxy behavior of the NAF will also be dis- cussed in more depth in section 3.5.
This section should have given you a rough idea of what the Generic Bootstrapping Architecture is and why it is needed. The next section will introduce the stan- dardization organizations that are important for this thesis and briefly discuss the specifications that provide the basis for the implementation.