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 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

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 GAA BSF (H-AAA) HLR/AC 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 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