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.
|
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.
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.
