1. 1 3GPP2 GBA Overview Adrian Escott Chair, TSG-S WG4 24 May 2006

2. 2 Aims of GBA To provide shared keying material that can be used to secure applications between a mobile and a network element –Avoids the need to provision new keys for each new service –Simplifies the development of new services, as there is a standard key management method –Re-uses the currently developed authentication method in order to generate the shared keying material –Simplifies adding new services to a legacy phone (that supports GBA), as no change is needed to a UIM to support key management –Also provides a method of generating shared keying material that does not leave the UIM (UIM enhancement needed) Using TLS-PSK with GBA key is complete (used in Presence Security) –Other security mechanisms using GBA key will be developed as needed

3. 3 Published GBA Specifications S.S0112 Generic Bootstrapping Architecture Requirements –Contains high level system requirements for GBA S.S0109 Generic Bootstrapping Architecture (GBA) Framework –Contains the architecture and architectural level requirements for GBA –Contains full description of the bootstrapping procedures (Ub interface) and stage 2 for the Zn and Zh interfaces S.S0114 Security Mechanisms using GBA –Contains TLS-PSK with GBA keys

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

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

6. 6 Ub interface Interface over which UE and BSF generate a shared key and agree a Bootstrapping Transaction identifier (B-TID) Uses HTTP Digest for CAVE and MN-AAA based bootstrapping, or HTTP Digest AKA for AKA based bootstrapping BSF selects bootstrapping method when UE supports more than one Covered in S.S0109 Additional methods of bootstrapping could be supported

7. 7 Ua interface This is the interface that will use the GBA derived keys to secure the application specific interface Application specific interface could be –Operator specific »Fully proprietary (only using key management from S.S0109) »Using method from S.S0114 (e.g. HTTPS using TLS-PSK with GBA keys) –Fully standardized »Fully standardized Ua interface (e.g. if BCMCS used GBA keys) »3GPP2 application using a method from S.S0114 (e.g. Presence security) In general it is necessary to include the following in a Ua protocol to enable it to use GBA keys –The UE and NAF agree on the NAF-ID (i.e. FQDN of the NAF and the Ua security protocol identifier) –The UE needs to pass the B-TID to the NAF –The NAF indicates to the UE that it can use bootstrapping (optional) »This may be mandated for a particular protocol

8. 8 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 particular NAF) using shared key, NAF-ID etc –BSF responds with Ks_NAF, Key lifetime and any required User Security Settings (application related security data that is needed by the NAF, e.g., user identity)

9. 9 Zh interfaces The Zh interfaces are used to retrieve authentication information from the relevant entity Assumption is that the BSF is always in the home system

10. 10 GBA_U GBA establishes session keys between the ME and the NAF An enhanced version called GBA_U also allows keys to be established between the UIM and the NAF –The bootstrapped and the UIM specific keys are not revealed outside of the UIM –Part of the application-specific NAF protocol could be 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. Possible with AKA and MN-AAA based bootstrapping

11. 11 Issues for TSG-C SWG1.4 MN-AAA GBA_U Bootstrapping AKA GBA_U Bootstrapping Ks_ext/int_NAF Generation

12. 12 GBA_U MN-AAA Bootstrapping First message –Input 128 bit BS_Challenge* and MS_Challenge* –Calculates and stores MN-AAA Authenticator as described –Returns 160 bit H0(MN-AAA Authenticator) Second message –Input 128 bit AKA_challenge and 160 bit Hash –Generates 128 bit random number and uses inputs and MN-AAA authenticator to calculate 256 bit Ks (stores this) and 128 bit RES –Return RES and random number Third message –Just a confirmation message –Store Ks and AKA_challenge to calculate keys later Fourth message –Input B-TID and lifetime –Stores these and keeps them available to be read by mobile

13. 13 GBA_U AKA Bootstrapping First message –Input RAND | AUTN* with both 128 bits long –Check AUTN* correct as described in S.S0109 (similar to AKA but with slight difference) –If AUTN OK calculates RES and Ks(=CK|IK) –Stores Ks and RAND for later key generation –Returns RES Second message –Same as fourth message of GBA_U MN-AAA Bootstrapping

14. 14 Ks_ext/int_NAF Generation Inputs NAF-ID, NAI and Key Derivation Parameter (Optional) From inputs and stored Ks and RAND/AKA_Challenge, the UIM calculates Ks_int_NAF and Ks_ext_NAF (both 256 bits long) Ks_int_NAF is stored along with B-TID and NAF-ID Ks_ext_NAF is returned to the mobile

15. 15 Thank you