This section gives a high-level description of the procedures used when a UE attempts to access a NAF that is protected by GAA.

Not every scenario is covered, just the common case. For further information, see the references.

Note In the descriptions below, assume the NAF and BSF have the fully-qualified domain names naf.home1.net and bsf.home1.net respectively. The home1.net domain is the network operator’s domain.

1. UE accesses NAF for the first time

The UE sends a request to the NAF naf.home1.net over HTTPS. No credentials are present in the request.

The NAF sees that the request is unauthorized, and sends back an HTTP 401 Unauthorized response. The response contains a WWW-Authenticate header, with the directive realm=3GPP-bootstrapping@naf.home1.net. This tells the UE that it needs to initiate bootstrapping procedure with the BSF, to create a new security association. The response also contains a nonce value which will be used when the UE contacts the NAF in step 3.

The UE indicates the authentication mechanism to use in all requests to access the NAF through the addition of a product token to the User-Agent header:

  • If the UE wishes to use GBA_ME authentication then it must include the product token 3gpp-gba in the User-Agent header

  • If the UE wishes to use GBA_Digest authentication then it must include the product token 3gpp-gba-digest in the User-Agent header on all requests to access the NAF.

  • If neither tokens are present in the User-Agent header the request is rejected without a challenge

The server responds with a WWW-Authenticate header if it supports the authentication mechanism requested by the client:

  • for GBA_ME the WWW-Authenticate header includes the directive realm=3GPP-bootstrapping@naf.home1.net

  • for GBA_Digest the WWW-Authenticate header includes the directive realm=3GPP-bootstrapping-digest@naf.home1.net.

2. UE initiates GBA bootstrap

Here the UE must contact the BSF to create a new security association. This process is known as "bootstrapping" and is specified by the Generic Bootstrapping Architecture (GBA) from 3GPP TS 33.220.

2.1. UE sends bootstrapping request to BSF

The UE sends an HTTP GET request to the BSF. The request’s Authorization header will have the subscriber’s private identity (IMPI) in the username directive. If the UE has previously created a temporary private identity (TMPI), this will be used instead of the IMPI. The nonce and response directives in the Authorization header are empty.

2.2. BSF sends Zh request to HSS

Next, the BSF sends a Zh request to the HSS using the Diameter protocol. If successful, the Zh response will contain an authentication vector (AV). This contains a 128-bit random number (RAND) and secrets derived from the shared key K.

The AV also includes the expected response (XRES). This is a large number derived from RAND that only the UE should be able to calculate, because of its knowledge of K.

The Zh response may also contain the subscriber’s GBA User Security Settings (GUSS), which, among other things, defines the lifetime of the security association.

2.3. BSF sends challenge

The BSF sends an HTTP 401 Unauthorized response back to the UE, containing the WWW-Authenticate header. This header contains the "challenge" in the form of the random value RAND, in the nonce directive.

2.4. UE sends challenge-response

The UE performs two calculations. Firstly, the K and RAND values are used to determine the response, known as RES. Secondly, the RES value is then used as the password for calculating the HTTP digest. The UE then sends a new HTTP GET request to the BSF, containing the Authorization header. The digest from the second calculation is sent in the Authorization header’s response directive.

2.5. BSF validates challenge-response

The BSF calculates the expected HTTP digest using XRES, and compares this with the value received in the response directive. If the values match, the bootstrapping was successful and the BSF creates and stores a new security association. This contains:

  • the Bootstrapping Transaction Identifier (B-TID) — this becomes the user ID used by the UE to access the NAF

  • the IMPI

  • a new shared key Ks, valid for the lifetime of the security association, used to generate a NAF-specific key.

The BSF sends an HTTP 200 OK response, containing an XML body specifying the new B-TID and the lifetime of the security association.

The GBA bootstrap process is now complete.

3. UE sends authorized request to the NAF

The UE can now proceed with the original request to the NAF. It calculates the NAF-specific key, known as Ks_NAF.

The new authorized request will contain an Authorization header using the HTTP Digest (RFC 2617) authentication scheme. The B-TID and Ks_NAF values are used as the username and password when calculating the message digest.

The UE calculates the request’s message digest, and sends this in the response directive of the Authorization header.

4. NAF checks the message digest

When the NAF receives the new request it contacts the BSF using the Zn interface to lookup the B-TID and calculate Ks_NAF.

The NAF performs the same digest calculation as the UE, and should arrive at the same value if the shared key is correct. Assuming the digests match, the request is considered authorized and the NAF can now process it securely.

Subsequent requests

Subsequent requests from the UE to the NAF do not need to go though all the previous steps. Once the UE knows the B-TID and Ks_NAF, it can reuse these values in subsequent requests for the lifetime of the security association. Each new request would just involve steps 3 and 4 above.

Bootstrapping does not need to be performed again until either the security association expires, or the NAF determines it is necessary based on local policy.

Previous page Next page