Download presentation
Presentation is loading. Please wait.
Published byDelilah Walton Modified over 9 years ago
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 Open Issues for TSG-X Where to store the GBA User Security Settings (GUSS)? How to select the authentication method for bootstrapping? –E.g. Stored in GUSS or policy in BSF. Stage 3 of the Zn interface Stage 3 of the Zh interfaces
12
12 GBA Security Settings (GUSS) GUSS is the collection of data about a particular subscriber that is using GBA The GUSS is made up of the following –Set of application specific User Security Settings (USS) –General information about the GBA usage for a particular subscriber »E.g. UIM capabilities - GBA_U capable USS contains the information needed for a specific application –User identities –Authorization information TSG-X needs to decide where to store the GUSS, e.g. BSF/HLR/HSS/AAA
13
13 Zn Interface Interface between the NAF and BSF that is used by the NAF to request and receive keys, USSs and other information from the BSF The above is the only interaction on this interface NAF sends –B-TID (Bootstrapping transaction identity) –NAF-ID (Ua security protocol identifier and agreed name of the NAF) –The identifiers of any USS it wants to receive –Key derivation parameter (optional) BSF checks if NAF is entitled to use the sent NAF-ID
14
14 Zn interface (cont) BSF responds with the following: –Ks_(ext_)NAF and/or Key Ks_int_NAF –Key lifetime –The time the bootstrapping was run –Requested USS that the NAF was authorized to receive
15
15 Zh interfaces 3 different Zh interfaces –Zh1 BSF to HSS –Zh2 BSF to HLR –Zh3 BSF to AAA Depending on the location of the GUSS, one or more of the Zh interfaces may be used to fetch the GUSS –This could be done separately or in conjunction with fetching authentication material
16
16 Zh interfaces (cont) Zh1 interface –Fetch AKA authentication vectors from HSS Zh2 interface –For CAVE based bootstrapping »Get RANDU, AUTHU pair »Use RAND, AUTHR pair to fetch SMEKEY and CDMAPLCM Zh3 interface –Fetch MN-AAA Authenticator
17
17 Thank you
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.