K.1 Example on interoperator GBA setup

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

Interoperator GBA is set up the following way:

– Each home network operator sets up a BSF, which will enable bootstrapping sessions for its own subscribers.

– Each operator acting as a Serving Network for foreign subscribers in interoperator GBA needs to set up a Zn-Proxy which will forward the authentication requests from its own NAFs to the subscriber’s home BSF outside of the VPLMN. The GBA secret is provisioned from the home operator’s BSF through the Zn-Proxy to the NAF.

NOTE 1: The security requirements on the Zn’ reference point between the Zn-Proxy and the BSF can be found in clause 4.2.2a.

– Each home operator that wants to provide the GBA secrets to foreign NAFs has to authorize these NAFs to request bootstrapping secrets. This is done by using TLS client certificates issued to Zn-Proxies in the serving network by the home network operator.

NOTE 2: The TLS client certificate profile is specified in the normative Annex E.

– An operator that wishes to co-operate in interoperator GBA with another operator shall issue a TLS client certificate to the other operator’s Zn-Proxy. Two operators may both act as home operators or as serving operators (i.e., both possess a BSF and a Zn-Proxy), but this Annex also applies to configurations where one operator is always acting as home operator (i.e., hosts the BSF) and the other operator only as serving operator (i.e., the operator hosts only the Zn-Proxy). In the second case, where the serving foreign operator has the Zn-Proxy only, the TLS client certificate is to be handed down in one direction only (see also Annex E on usage of client certificates).

NOTE 3: The handling of TLS certificates is described in TS 33.310 [19]. When two operators sign a roaming agreement, they may also enrol TLS client certificate for each others Zn-Proxies.

NOTE 4: Interoperator GBA is based on bilateral agreements between the two operators. For example, if operator1 has a "GBA agreement" with operator2 and operator1 signs another "GBA agreement" with operator3, this does not mean that operator3 and operator2 have implicitly a "GBA agreement". Operator2 and operator3 shall separately sign a "GBA agreement".

NOTE 5: The home operator may use NAF groups to support local policy checks within its BSF (cf. clause 4.2.1). These may be e.g. one group for NAFs in home network and one group for NAFs in serving networks, or separate groups for each serving network the home operator has "GBA agreements" with. This NAF grouping is under sole responsibility of the home operator and only visible to him. The Zn-Proxies and NAFs in serving networks are not aware of any NAF grouping done in home network.

As described in clause 4.2.2a, a Zn-Proxy may be co-located with a BSF (see Figure K-2). This has the benefit that the NAF has only one logical channel to BSF/Zn-Proxy. Therefore the NAF does not need to make a decision based on the B-TID whether to send the authentication request to the Zn-Proxy or to the BSF. However, this decision can be based on the B-TID as it contains the address of the BSF.

Figure K-1: Interoperator GBA with separate BSF and Zn-Proxy

NOTE 6: The figure K-1 does not show the most general case, where there could be one Zn-proxy per home network in each serving network. It is expected that networks will be optimized and that the existence of one dedicated Zn-proxy for each foreign subscriber home network will be a rare occurrence. The co-location of all Zn-Proxies of one serving network in one location as shown in Figure K-1 is a special case.

NOTE 7: The TLS connections between Zn-Proxy and BSF are "directed", this is indicated in Figure K-1 by the arrowed lines where the arrows point to the server TLS role. The role of the client certificates in these TLS connections is explicitly outlined. Each direction requires a TLS server certificate used at BSF and a TLS client certificate used at Zn-Proxy.

Figure K-2: Interoperator GBA with co-located BSF and Zn-Proxy

NOTE 8: The two distinct TLS connections between Zn-Proxy and BSF are "directed", this is indicated in Figure K-2 by the two lines. Thus the two TLS connection directions may not be intermixed, as the role of the client certificates in these TLS connections is explicitly outlined. Each direction requires a server TLS certificate used at BSF and a client TLS certificate used at Zn-Proxy.