K.2 Example on interoperator GBA operation

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

Interoperator GBA usage goes as follows:

NOTE 1: This description is based on GBA_ME bootstrapping to simplify the examples, but GBA_U bootstrapping can also be used in interoperator GBA operation.

1. A UE contacts a NAF that does not belong to subscriber’s home network. The foreign NAF notifies the UE that 3GPP bootstrapping is required to secure the connection between the UE and the NAF.

2. The UE bootstraps with the home network via the subscriber’s BSF. The address of subscriber’s home BSF is generated from user’s IMSI or IMPI as specified in TS 33.220, clause 4.5.4. The key Ks, and the B-TID are established between the BSF and the UE.

3. The UE derives the NAF specific key Ks_NAF, and uses Ks_NAF and the B-TID on the Ua reference point between the UE and the foreign NAF. At some point during this setup the UE transfers the B-TID to the NAF in the serving network.

4. Upon receiving the B-TID, the foreign NAF has two modes of operations depending on the actual setup of the Zn-Proxy and the BSF in the serving network:

NOTE 2: Any BSF in a network different from the home network of a subscriber and any Zn-Proxy are not visible to the subscriber. To avoid any confusion with the subscribers BSF in the home network, the BSF in a visited network is called foreign BSF in this clause.

a) If the Zn-Proxy and the foreign BSF are separate entities, the foreign NAF shall inspect the B-TID to discover whether the subscriber belongs to its own network, or whether it is a visiting subscriber. In the former case, the request for the Ks_NAF is sent to the BSF, in the latter case, the request is sent to the Zn-Proxy.

b) If the Zn-Proxy and the foreign BSF are a co-located entity, the NAF sends the request for the Ks_NAF to this co-located entity. The NAF does not need to inspect the B-TID.

NOTE 3: Since the B-TID contains the address of subscriber’s home BSF, it can be used to discover the home network of the subscriber. A NAF supporting this approach can work with both separated and co-located configurations.

5. Upon receiving the request from the NAF, the Zn-Proxy shall inspect the following:

b) Validate that the NAF is authorized to request the Ks_NAF (i.e., the DNS part of NAF_Id in the message is correct).

b) Discover the BSF of the subscriber by inspecting the B-TID.

6. The Zn-Proxy will establish or use the existing DIAMETER or HTTP session to subscriber’s home BSF. This DIAMETER or HTTP session is secured by TLS, and the Zn-Proxy shall use a client certificate that the BSF trusts.

7. The Zn-Proxy will forward the request to subscriber’s home BSF.

8. Subscriber’s home BSF shall validate that the DNS part of the NAF_Id in the request also exists in the client certificate of the Zn-Proxy.

9. Subscriber’s home BSF locates the bootstrapping information using the B-TID, processes the request (including possible requests for USSs, local policy check, etc.), derive the NAF specific key, and send the response to the Zn-Proxy.

10. The Zn-Proxy will forward the response to the NAF.

11. The NAF continues with the Ua connection establishment with the UE.

Figure K-3 depicts the entities involved in the above procedure.

Figure K-3: Interoperator GBA usage

Annex L (informative):
Information on how security threats related to known GSM vulnerabilities are addressed by the 2G GBA solution

The 2G GBA solution aims to provide mutual authentication between UE and BSF. This annex examines how the 2G GBA solution mitigates the impersonation of UE or the BSF i.e. security threats related to the known GSM vulnerabilities.

The threats that are originated from the weakness in the usage of the COMP128 algorithm exist independently of the usage of 2G GBA.