Readers are probably familiar with the use of the Authentication and Key Agreement (AKA) mechanism in IMS. An IMS mobile device, or UE, has a ISIM or USIM that shares a secret with the 3GPP Authentication Center. It uses the AKA-digest mechanism in SIP to authenticate with its S-CSCF, and as a side-effect, generate the keying material for an IPSec ESP security association between the UE and the P-CSCF. But what about non-SIP applications? How would a carrier authenticate and authorize applications over other protocols, such as HTTP?
Enter the 3GPP Generic Bootstrap Architecture (GBA). The GBA is part of the Generic Authentication Architecture (GAA). UEs can use the GBA for shared-secret based authentication. The GAA also includes a parallel architecture for Public Key Infrastructure (PKI) based authentication, called Support for Subscriber Certificates (SCC). GAA is described in 3GPP TR 33.919. GBA is described in 3GPP TS 33.220 .
GBA is a generalization of IMS AKA. It differs from IMS AKA authentication in that it supports arbitrary application protocols, while IMS AKA only supports SIP. For example, GBA could be used to authentication Web-based applications, or even access to an XDM, over HTTP. It could be used to authenticate email access. It could even be used for SIP applications, although since IMS already uses AKA over SIP, the author does not expect to see GBA authentication in IMS applications anytime soon.
The figure below illustrates GBA (thanks to my associate Ajay Deo for the original picture on which this one is based).
At its core is the Bootstrapping Server Function (BSF). The BSF implements four primary interfaces:
Ub – HTTP interface to the UE
Dz – Diameter interface to the Server Location Function (SLF)
Zh – Diameter interface to the Home Subscriber Server (HSS)
The Network Application Function (NAF) is an abstract placeholder for an application server for some arbitrary application protocol.
At a very high level, GBA operates as follows: The UE attempts to invoke some application at the NAF. Let’s imagine that this application is based on HTTP. The NAF then returns an indicator that the UE must first authenticate with the BSF. The UE then performs an HTTP digest-AKA handshake with the BSF. The BSF checks with the SLF to find the HSS for the given user, then retrieves the authentication vector (AV) and GBA User Security Settings (GUSS) for that user from the HSS.
Assuming success so far, the BSF derives an application specific key (Ks_NAF) from the AV, and constructs a Bootstrapping Transaction Identifier (B-TID), and hands the B-TID (but not the Ks_NAF) back to the UE. Since the UE’s USIM or ISIM contains a copy of the same master key that the BSF used to derive Ks_NAF, it can reconstruct that on its own.
The UE then tries again to communicate with the NAF, this time using B-TID and Ks_NAF as its credentials. The NAF recognizes B-TID, and queries the BSF to get the Ks_NAF value associated with that B-TID, as well as relevant parts of the GUSS. The NAF can then complete the authentication of the UE using its application specific portico. (For example, if the application protocol is HTTP, this could be a normal (as in non-AKA) HTTP Digest authentication.)
The NAF does not have to be in the same network as the BSF. This could be extremely useful if carriers outsource services to the cloud, but wish to retain control of user identities. In the roaming case, GBA calls for a “Zn Proxy” that lives in the visited network, and intermediates communication to a BSF in the home network.
There are a few variations on this theme. The 3GPP GBA definition defines a Zh interface that the BSF can use to communicate with some legacy device in the HSS role that does not support Zh, such as an HLR or a legacy HSS. The Dz interface is optional for cases where the BSF talks to a single HSS node for all users. 3GPP2 has defined a version of GBA that can use an IS-41 interface to an HLR, or a RADIUS interface to a AAA service.