GBA/GAA

GBA stands for Generic Bootstrapping Architecture and GAA stands for Generic Authentication Architecture. 33.220 splits the mechanism in two. Clause 4 describes GBA_ME, which needs no change to the UICC. Clause 5 describes GBA_U, which does change the UICC and keeps some derived keys on it.

This is a kind of mechanism by which a system can share the authentication information (more specifically, the result of authentication) with another system. The authentication information here does not mean 'user id/password' or 'Authentication Key stored in SIM card'. It is more like the information that can be created (processed in a special way) as a result of Authentication that has already been done in a system.

Why GBA ?

Usually we can say the Authentication mechanism being used in Cellular Network (mostly based on UICC) is much robust and strong comparing to the mechanism being used in other system (e.g, small-scale application service provider). These days, many people are accessing those application service provider through mobile phone and the user has to be authenticated by the service provider via mobile phone. In this case, it would be very good in many ways if those application service can be authenticated by the authentication information provided by the network operator. If this can be doable, those application service provider can utilize those strong authentication mechanism that is provided by Cellular authentication algorithm and Network operator with relatively low cost and at the same time the user experience for the subscriber will be improved as well since they do not need to go through typing in user credentials for authentication. Also, they don't need to remember so many different user IDs and passwords for each service providers. This is the main motivation of GBA.

I think the statement from 3GPP TS 133.220 4 Generic Bootstrapping Architecture is hinting on the motivation of adopting GBA as quoted below.

The 3GPP authentication infrastructure, including the 3GPP Authentication Centre (AuC), the USIM or the ISIM, and the 3GPP AKA protocol run between them, is a very valuable asset of 3GPP operators. It has been recognised that this infrastructure could be leveraged to enable application functions in the network and on the user side to establish shared keys. Therefore, 3GPP can provide the "bootstrapping of application security" to authenticate the subscriber by defining a Generic Bootstrapping Architecture (GBA) based on AKA protocol.

Basic Architecture of GBA

Following is the basic architecture of GBA specified in Figure 4.1 of 3GPP TS 133.220. This is the most basic architecture and there are a couple of more variations of the architecture that you can refer to in the specification.

The most important component here is BSF and NAF ('F' means 'Function'. You may take this as a kind of 'Server' or 'Proxy')

Five boxes and five reference points. The UE sits at the bottom, the BSF in the middle, the NAF on the right, and the HSS above the BSF.
Ub joins the UE to the BSF. The bootstrapping run happens there, and it is where the shared secret comes from.
Ua joins the UE to the NAF. That is the application traffic the whole exercise exists to protect.
Zh joins the BSF to the HSS, and the BSF fetches an authentication vector over it.
Zn joins the BSF to the NAF, and the NAF collects its key over it.
Dz joins the BSF to the SLF. A network with more than one HSS needs it to learn which HSS holds the subscriber.

The shape is the point. The UE and the NAF never hand each other a key. Each gets one from the BSF, over a different reference point. The two values agree because both sides run the same derivation on the same inputs.

That is also why the operator keeps control. The NAF cannot serve a bootstrapped session without asking the BSF over Zn, so the subscription still decides who gets access.

The BSF is the only node that talks to both sides : the UE reaches it over Ub and the NAF over Zn.
Ua carries the application, not the bootstrapping : the key is already in place by the time Ua is used.
Zh is where the cellular credential enters : the BSF pulls an authentication vector from the HSS and nothing weaker is involved.
Dz only matters in a multiple HSS network : the SLF answers which HSS holds a given subscriber.

How UE discover BSF Address ?

How does UE can figure out BSF address ? According to 3GPP specification (23.003 16.2 BSF address), it can be derived from UICC and ISIM parameters as illustrated below.

The UICC supplies the IMSI, and the first five or six digits of it are the MCC and the MNC.
A two digit MNC gets a zero in front, which is the decision box in the middle of the picture.
Those two fields fill the template bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org.

23.003 gives the worked example. An IMSI of 234150999999999 has MCC 234 and MNC 15, so the MNC becomes 015 and the address comes out as bsf.mnc015.mcc234.pub.3gppnetwork.org.

The leading zero is what the decision box exists for. Without it a two digit MNC and a three digit MNC could produce the same label, and two operators would collide on one name.

An ISIM starts somewhere else. It carries an IMPI rather than an IMSI, and the domain half of that identity already names the home network. The rule below reuses that domain instead of rebuilding one from MCC and MNC.

The decision is whether the IMPI domain ends in 3gppnetwork.org.
If it does, the last two labels are replaced by pub.3gppnetwork.org and bsf is put in front. Everything between is carried over unchanged.
If it does not, the rule is simply to put bsf in front of the domain.

23.003 works both branches through. An IMPI of 234150999999999@ims.mnc015.mcc234.3gppnetwork.org gives bsf.ims.mnc015.mcc234.pub.3gppnetwork.org. An IMPI of user@operator.com gives bsf.operator.com.

Both routes end in a name the UE resolves by DNS. Nothing is provisioned and nothing is configured, which is what lets a UE find a BSF it has never been told about.

The address is derived, never provisioned : the UICC already holds everything the rule needs.
USIM starts from the IMSI, ISIM from the IMPI : and the two rules meet at the same kind of name.
The zero fill keeps two digit and three digit MNCs apart : 23.003 states it as the first step of the USIM rule.
A non 3GPP domain is left alone : bsf goes in front of it and nothing else changes.

How GBA is initiated ?

The trigger matters here, because nothing in GBA starts on a timer. Bootstrapping begins when an application asks for it, and the picture below shows which side does the asking.

How this GBA process get triggered (initiated) ? It is initiated as a result of communication between UE and NAF. ("UE" here would mean a specific Application on UE. Not all application/services would go through this process). Following is overall initiation process, refer to 33.220 4.5.1 for further details.

The lanes are UE, NAF, BSF and HSS or SLF, and the first two carry everything that follows.
Step 1 is an ordinary request from the UE to the NAF over Ua, sent with or without GBA parameters.
The first decision asks whether the NAF requires GBA at all. A no means GBA is not used, and the request is served normally.
The second decision asks whether the request already carried GBA parameters. A yes goes straight to the bootstrapping process.
A no produces step 2, the bootstrapping initiation required message, which sends the UE to the BSF before it tries again.

33.220 clause 4.5.1 states the same thing in two sentences. The UE may open over Ua with or without GBA parameters. A NAF that needs GBA and did not receive them replies with a bootstrapping initiation message.

Clause 4.5.2 adds the other two ways in. A UE that already knows bootstrapping is needed goes straight to the BSF, and so does a UE whose key lifetime has expired.

The NAF decides, not the network : GBA starts because an application asked for a key it does not have.
Three routes reach the same procedure : the UE knows already, the NAF tells it, or the key it holds has expired.
The initiation message is Ua specific : 33.220 leaves its form to whatever protocol Ua is carrying.
A request that already carries GBA parameters skips step 2 : which is the yes branch on the right of the picture.

How the process goes on ?

Once GBA process is initiated by various triggers, UE goes through Bootstrapping Procedure. This procedure may vary a little bit depending on cases. In this section, a couple of types of Bootstrapping will be introduced (Most of the details are based on 3GPP 33.220 4.5.2, 4.5.3)

Steps 1 to 5 are one HTTP Digest AKA exchange between the UE and the BSF over Ub. The UE identifies itself with an IMPI, or a TMPI if it holds one.
Steps 2a and 2b are the only time the HSS appears. The BSF fetches an authentication vector, and the note under the diagram gives its five parts.
Step 3 is a 401 carrying RAND and AUTN, which is the AKA challenge wrapped in an HTTP header.
Step 4 happens inside the UE. It checks AUTN, and only then computes CK, IK and RES.
Steps 6 to 9 finish the run. The BSF checks RES, both sides build Ks by concatenating CK and IK, and both derive the same Ks_NAF.

Step 8 is where the UE learns what to call the result. 33.220 has the BSF return a 200 OK carrying the B-TID and the lifetime of Ks. The B-TID is built as the base64 encoded RAND, an at sign, and the BSF server name.

The arrow for step 8 points the wrong way in the picture above. Clause 4.5.2 states that the BSF sends the 200 OK to the UE, which is the only direction that makes sense for a response.

The B-TID is what makes the rest work. The UE hands it to the NAF over Ua, and the NAF hands it to the BSF over Zn. The BSF then uses it to find the Ks it already holds.

The whole run is HTTP Digest AKA : 33.220 borrows the protocol rather than inventing one.
The secret never crosses Ub : RAND and AUTN go out, RES comes back, and CK and IK are computed at both ends.
Ks is CK and IK concatenated : the same value appears at the UE and at the BSF without being sent.
The B-TID is an identifier, not the key : it names a bootstrapping run so the NAF can ask the BSF for the key.

Note : 'AV' in this diagram stands for 'Authentication Vector' and it is defined as AV = RAND||AUTN||XRES||CK||IK

What kind of Keys are used and how they are derivied ?

Two keys are named below, and which one a deployment uses depends on where the derivation runs. That choice is the difference between the two flavours of GBA, and it decides whether a key can ever leave the card.

The most important Keys in GBA process are Ks_int_NAF and Ks_ext_NAF and they are derived as follows.

Ks_ext_NAF = KDF(Ks, "gba-me", RAND, IMPI, NAF_Id)
Ks_int_NAF = KDF(Ks, "gba-u", RAND, IMPI, NAF_Id)

KDF stands for Key Derivation Function and it is described in 33.220 Annex B (normative): Specification of the key derivation function KDF

The pair above belongs to GBA_U, which is the flavour with UICC based enhancements. 33.220 clause 5.3.2 computes both in the UICC, and the two differ only in the constant string fed to the derivation.

The split is the whole point of GBA_U. Ks_ext_NAF is handed out to the ME, and Ks_int_NAF stays on the UICC and is never released. An application that needs a key the handset cannot read uses the second one.

Plain GBA_ME has neither. Clause 4.5.2 derives a single Ks_NAF with the same gba-me string, and the ME does the work. Nothing stays behind on the card.

One input deserves a note. NAF_Id is the FQDN of the NAF followed by the Ua security protocol identifier. Two applications on the same server therefore share a key unless their protocol identifiers differ.

The two keys above are the GBA_U pair : 33.220 computes both inside the UICC.
Only the constant string differs : gba-me produces the external key and gba-u the internal one.
Ks_int_NAF never leaves the card : which is what an application gains when it needs a key the ME cannot read.
GBA_ME derives one key instead of two : the ME computes Ks_NAF and nothing remains on the UICC.
The NAF identity is part of the derivation : NAF_Id is the FQDN followed by the Ua security protocol identifier.

Reference

[1] 33.220 : 3GPP - Generic Authentication Architecture; Generic Bootstrapping Architecture, v19.1.0. Clause 4.1 gives the reference model quoted above, 4.2 the network elements, 4.5.1 the initiation, 4.5.2 the nine step bootstrapping run, and 5.3.2 the GBA_U key pair.

[2] 23.003 : 3GPP - Numbering, addressing and identification, v20.0.0. Clause 16.2 gives the BSF address rules for USIM and ISIM, and the three worked examples quoted above.