As TR 33.919 [15] describes, the GAA – Generic Authentication Architecture is a mechanism created in order to address the need of certain applications for authentication. Initially created for application servers like presence, PKI portals or MBMS content server, this mechanism establishes a basis for any future mutual authentication needs of the applications, including the one described in this paper, IMS. The overall GAA architecture is composed of two main mechanisms: GBA – Generic Bootstrapping Authentication, described in TS 33.220 [13], which uses shared secrets, and SSC – Support for Subscriber Certificates [16]. Both these specifications describe ways to generate the authentication material and distribute it to the peers, being based on the AKA – Authentication and Key Agreement protocol or on an EAP – Extensible Authentication Protocol framework using the AKA method.
The GBA architecture can be described, in a simple manner, as having six elements: HSS, BSF, NAF, ZnProxy, SLF and UE. The figure below presents a simple network architecture for GBA when the Home Network and Visited Network are different network, separated by untrusted networks.
GBA architecture
The HSS – Home Subscriber Server is the database system that stores the user’s authentication credentials, generically named USS – User Security Settings (for example: GUSS – GBA User Security Settings), being the only entity that permanently stores these credentials. It has the purpose of mapping the GUSS to one or more private identities, but a private identity can only have at most one GUSS associated; a private identity in IMS is called IMPI – IP Multimedia Private Identity. The GUSS format has many parameters, but the ones specifically needed here by the BSF are the following: the type of UICC used, the lifetime of the key generated for the subscriber and, optionally, the timestamp when the GUSS was modified in the HSS and they are sent by the HSS to the BSF via the Zh interface.
The BSF – Boostrapping Server Function is the entity that connects to the HSS via the Zh interface, in order to authenticate the user. The negotiation between the BSF and the UE is done via the Ub interface, and it runs the AKA protocol. The BSF connects to the HSS, retrieves the GUSS from the HSS, along with an AV – Authentication Vector – which contains a pair of 5 values: RAND, AUTN, XRES, IK, CK. The BSF forwards RAND and AUTN to the UE. The UE – User Equipment has an UICC – Universal Integrated Circuit Card, which computes the IK, CK, MAC and RES based on the RAND and AUTN fields received from the BSF. The UE also verifies the MAC in order to authenticate the network, then it obtains the Ks by concatenating the IK and CK and sends the RES back to the BSF, in order to be authenticated by the network. The BSF verifies the RES against the XRES it has computed and, if they match, the UE is authenticated. If this happens, the BSF computes a Ks key, sends back to the UE a B-TID – Bootstrapping Transaction Identifier and the lifetime of the Ks. Both the UE and the BSF store this Ks and the B-TID for further use. The UE also stores the RAND value.
The NAF – Network Application Function is the generic server contacted by the UE. As per the Spec, there is no prior security association between the UE and the NAF. The BSF has the role to derive a Ks_NAF key and send it to the NAF via the Zn interface, while the UE also generates a Ks_NAF key. Of course, the BSF of that specific UE and the NAF this UE tries to connect to must have connectivity to each other, otherwise the key exchange is not be possible. Also, the NAF must have connectivity to the BSF of that UE, because it may need to access the HSS and get GUSS of the UE. The structure of the NAF is organized in policies: there are local policies that indicate whether a specific UE can have access or not to a certain application functionality. Also, in the application-specific USS there can be a key selection indication. When this happens, and if the NAF supports UICC-based enhancements for GBA (GBA_U), then this key selection indication overwrites the local policy of the NAF.
The BSF should keep a list of NAFs and a list of groups of NAFs, in order to be able to identify at any given moment which NAF should be chosen if an application-specific USS appears. The definition of the NAFs in a group and the connection between these groups and the BSFs is in the implementation decision of the operator.
The ZnProxy entity appears in the architecture in the moment when the UE is in the visited network, the NAF is also operated by this visited network, but the BSF managing this UE is located in the home network. The ZnProxy may be a separate device, but it is usually in the functionality of an already existing device that has another primary role in the network: that of the visited NAF, the visited AAA server or an HTTP server – nevertheless, it must support Diameter and/or HTTP proxy functionality. The purpose of the ZnProxy in this architecture is to locate the UE’s home BSF, to make sure it can securely connect to this device and to connect to it and send it the visited NAF DNS name.
The SLF – Subscriber Locator Function is the entity queried by the BSF over the Dz interface to identify the HSS that contains the information about a specific UE. Just as with the IMS, this entity appears when there are multiple HSS devices.
Tags: BSF, HSS, IMS, LTE, NAF, SAE, security, SLF, techie, UE
