3GPP GBA Overview Adrian Escott
Health Warning • The details of interfaces may change but the overall the architecture is table.
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
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(?)
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.
GBA message flows HSS/HLR/AAA 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
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
Bootstrapping with AKA
Bootstrapping in CDMA 1x (with CAVE) – SMEKEY is used as password 1x Terminal CAVE BSF (H-AAA) HLR/AC GAA Ub Zh 1. GET / HTTP/1.1 Authorization: Digest username=“IMSI@realm.com” 2. Generate RAND (the global challenge) 3. HTTP/1.1 401 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/1.1 200 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).
Bootstrapping in CDMA 1x EvDo (with CHAP) – MN-AAA Authenticator is used as password
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)
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)
Zh interface • Zh interface is used to retrieve authentication information from the relevant entity • Assumption that BSF is always in home
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.
Using GBA • GBA with TLS • 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
