1. 3GPP GBA Overview
Adrian Escott

2. Health Warning
The details of interfaces may change but the overall the architecture is table.

3. Aims of GBA
To provide shared keying material that can be used to secure some application between a mobile and a network work element
Avoids the need to provision new keys for each new service
Simplifies the development of new services, as there is a ready management method
Re-uses the current developed authentication method to generate the shared key material
Simplifies adding new services to old phone (that support GBA), as no change needed to UIM to support key management
Also provide method of generating shared key material that doe not leave the UIM
Methods being developed how to use GBA with different security mechanisms
E.g Using GBA with TLS, proposed for Presence Security

4. GBA Specifications
S.P0112 General Bootstrapping Architecture Requirements
Contains high level system requirements for GBA
S.P0109 General Bootstrapping Architecture
Contains the architecture and architectural level requirements for GBA
Contains description of bootstrapping procedures, Zn and Zh interfaces
S.P0114 “Security Mechanisms using GBA”
Will contain descriptions of using GBA with various security protocols, i.e. Ua interface
Initial protocols will include TLS and Digest(?)

5. GBA Architecture
Bootstrapping Server Function (BSF) and UE mutually authenticate and agree on a shared key.
Once that shared key is available, UE and Network Application Function (NAF) can communicate securely using a key material derived from this shared key.
HSS/HLR/AAA are used to provide the necessary data for BSF and UE to authenticate each other and generate shared key.

6. GBA message flows HSS/HLR/AAA BSF NAF UE
4. BSF request authentication info
6. NAF requests key from BSF
7. BSF sends key to NAF
BSF
NAF
8. NAF send response
5. UE send request including B-TID
2. NAF responds with request for bootstrapping
3. UE and BSF perform bootstrapping UE
1. UE contacts NAF for service

7. Ub interface Interface over which UE and BSF generate shared key
Will use HTTP Digest for CAVE and CHAP based bootstrapping and HTTP DIGEST AKA for AKA based bootstrapping
BSF selects bootstrapping method when UE supports more than one included.
Covered in S.P0109
Additional methods of bootstrapping could be supported provided that they
Result in key shared between UE and BSF
Allow the Bootstrapping Transaction Identity (B-TID) to be sent to the UE
Allow the Key expiry time to be sent to the UE

8. Bootstrapping with AKA

9. Bootstrapping in CDMA 1x (with CAVE) – SMEKEY is used as password
1x Terminal
CAVE
GAA
BSF (H-AAA)
HLR/AC Ub Zh
1. GET / HTTP/1.1
Authorization: Digest
2. Generate RAND (the global challenge)
3. HTTP/ Not authorized
WWW-Authenticate: Digest nonce=“<RAND>”, qop=“auth-int”, …
4. RAND
5. AUTHR, SMEKEY, …
6. Set parameters:
MS_PW = SMEKEY
H1’(MS_PW) • gx mod p
x is secret random number generated by UE
7. GET / HTTP/1.1
Authorization: Digest nonce=“<RAND>”, response=“<MS_PW used as passwd>”, qop=auth-int, …
(in HTTP playload “H1’(MS_PWD) • gx mod p” is delivered, and AUTHR)
8. AUTHREQ (AUTHR, RAND, …)
9. Verifies RAND/AUTHR, generates SMEKEY
10. Authreq (SMEKEY, …)
11. Set parameters:
BS_PW = SMEKEY
H1’(BS_PW) • gy mod p
y is secret random number generated by UE
12. Generate GAA master key (Ks) from BS_PW (the same way as WKEY).
13. HTTP/ OK
Authentication-Info: Digest respauth=“<BS_PW used as passwd>, qop=auth-int, , …
(in HTTP playload “H1’(BS_PW) • gy mod p”, B-TID, and key lifetime are delivered)
14. Generate GAA master key (Ks) from PS_PW (the same way as WKEY).

10. Bootstrapping in CDMA 1x EvDo (with CHAP) – MN-AAA Authenticator is used as password

11. Ua interface
This is the interface that will use the keys to secure the protocol
Details will be specified in S.P0114
Idea is keep this very general and make reference to it in Service specific document.
E.g. specify how to use TLS with GBA in S.P0114 and reference this in a service specification.
Location (X.P0024 and S.P0110) are an example of this in practice.
In general it is necessary to include the following in a protocol to enable it to use GBA keys
The UE and NAF agree on the name of the NAF
The UE needs to pass the B-TID to the NAF
The NAF needs to fetch the GBA derived key from the BSF once it has the B-TID.
The NAF may need to interact with the BSF to generate its GBA key (optional)
The NAF indicates to the UE that it can use bootstrapping (optional)

12. Zn interface
This is used by the NAF to request keys and other related information from the BSF
There is only one type of interaction on this interface
NAF sends B-TID, NAF-ID, Random numbers (optional) , … to the BSF
BSF calculate Ks_NAF (key for that particluar NAF) using shared key, NAF-ID etc
BSF responds with Ks_NAF, Key lifetime and User Security Settings (application related data that is needed by NAF, e.g. user identity)

13. Zh interface
Zh interface is used to retrieve authentication information from the relevant entity
Assumption that BSF is always in home

14. GBA_U GBA establishes session keys between the ME and the NAF
An enhanced version called GBA_U allows keys to be established between UIM and NAF
The keys are not revealed outside the UIM
The application-specific NAF protocol is implemented on the UIM
This enhancement offers a higher level of security which is needed for certain applications, e.g. for BCMCS if GBA was used to provide RK.
Method for AKA has been accepted
It was agreed not to modify CAVE to do GBA_U
A method for CHAPS is FFS.

15. Using GBA GBA with TLS GBA with Digest
TLS PSK using GBA generated keys
Use GBA keys as Pre-shared Keys for TLS
Certificate based server authentication with Digest based client authentication
Certificate management issues
Must ensure tunnel endpoints are the same
GBA with Digest
Needed for second of above – useful in own right?
If so, could be included in S.P0114