8.39 GBA Authentication / 5GS

34.229-53GPPInternet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Part 5: Protocol conformance specification using 5G System (5GS)Release 16TSUser Equipment (UE) conformance specification

8.39.1 Test Purpose (TP)

(1)

with { UE being registered to IMS and configured to use GBA authentication }

ensure that {

when { UE is made to activate OIP }

then { UE authenticates itself using GBA }

}

8.39.2 Conformance Requirements

The conformance requirements covered in the present test case are, unless otherwise stated, Rel-15 requirements.

[TS 24.109, clause 4.2]:

The UE shall initiate the bootstrapping procedure when:

a) the UE wants to interact with a NAF and bootstrapping is required;

b) a NAF has requested bootstrapping required indication as described in subclause 5.2.4 or bootstrapping renegotiation indication as described in subclause 5.2.5; or

c) the lifetime of the key has expired in the UE if one or more applications are using that key.

A UE and the BSF shall establish bootstrapped security association between them by running bootstrapping procedure. Bootstrapping security association consists of a bootstrapping transaction identifier (B-TID) and key material Ks. Bootstrapping session on the BSF also includes security related information about subscriber (e.g. user’s private identity). Bootstrapping session is valid for a certain time period, and shall be deleted in the BSF when the session becomes invalid.

Bootstrapping procedure shall be based on HTTP Digest AKA as described in 3GPP TS 33.220 [1] and in RFC 3310 [6] with the modifications described below.

The BSF address is derived from the IMPI or IMSI according to 3GPP TS 23.003 [7].

A UE shall indicate to the BSF that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "User-Agent" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP requests sent to the BSF.

A BSF shall indicate to the UE that it supports the use of TMPI as defined in 3GPP 33.220 [1] by including a "product" token in the "Server" header field (cf. RFC 2616 [14]) that is set to a static string "3gpp-gba-tmpi" in HTTP responses sent to the UE.

In the bootstrapping procedure, Authorization, WWW-Authenticate, and Authentication-Info HTTP headers shall be used as described in RFC 3310 [6] with following exceptions:

a) the "realm" parameter shall contain the network name where the username is authenticated;

b) the quality of protection ("qop") parameter shall be "auth-int"; and

c) the "username" parameter shall contain user’s private identity (IMPI).

NOTE: If the UE does not have an ISIM application with an IMPI, the IMPI will be constructed from IMSI, according to 3GPP TS 23.003 [7].

In addition to RFC 3310 [6], the following apply:

a) In the initial request from the UE to the BSF, the UE shall include Authorization header with following parameters:

– the username directive, set to

1) the value of the TMPI if one has been associated with the private user identity as described in 3GPP 33.220 [1]; or

2) the value of the private user identity;

– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];

– the uri directive, set to either absoluteURL "http://<BSF address>/" or abs_path "/", and which one is used is specified in RFC 2617 [9];

– the nonce directive, set to an empty value; and

– the response directive, set to an empty value;

b) In the challenge response from the BSF to the UE, the BSF shall include parameters to WWW-Authenticate header as specified in RFC 3310 [6] with following clarifications:

– the realm directive, set to the BSF address derived from the IMPI or IMSI according to 3GPP TS 23.003 [7];

c) In the message from the BSF to the UE, the BSF shall include bootstrapping transaction identifier (B-TID) and the key lifetime to an XML document in the HTTP response payload. The BSF may also include additional server specific data to the XML document. The XML schema definition of this XML document is given in Annex C.

d) When responding to a challenge from the BSF, the UE shall include an Authorization header containing a realm directive set to the value as received in the realm directive in the WWW-Authenticate header.

e) Authentication-Info header shall be included into the subsequent HTTP response after the BSF concluded that the UE has been authenticated. Authentication-Info header shall include the "rspauth" parameter.

After successful bootstrapping procedure the UE and the BSF shall contain the key material (Ks) and the B-TID. The key material shall be derived from AKA parameters as specified in 3GPP TS 33.220 [1]. In addition, BSF shall also contain a set of security specific attributes related to the UE.

An example flow of successful bootstrapping procedure can be found in clause A.3.

8.39.3 Test description

8.39.3.1 Pre-test conditions

System Simulator:

– 1 NR Cell connected to 5GC, default parameters.

UE:

– UE contains either ISIM and USIM applications or only USIM application on UICC.

– UE is configured to register for IMS after switch on.

Preamble:

– UE is in state 1N-A (TS 38.508-1 [21]) and registered to IMS

8.39.3.2 Test procedure sequence

Table 8.39.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

UE is made to attempt to attempt activation of supplementary service Originating Identification Presentation

–

–

–

–

2

UE sends an initial HTTP Request
(Step 2 of A.21)

–>

GET/PUT/DELETE

–

–

3

Conditional (according to A.21):
SS sends 401 Unauthorized
(Step 3a of A.21)

<–

401 Unauthorized

–

–

4

UE sends HTTP request
(Step 1 of A.22)

–>

GET

–

–

5

SS sends 401 Unauthorized
(Step 2 of A.22)

<–

401 Unauthorized

–

–

6

UE sends HTTP request with valid authorization credentials
(Step 3 of A.22)

–>

GET

1

P

7

SS sends 200 OK
(Step 4 of A.22)

<–

200 OK

–

–

8

Conditional (according to A.21):
UE sends HTTP request with valid authorization credentials
(Step 3b of A.21)

–>

GET/PUT/DELETE

–

–

9

SS sends 200 OK
(Step 4 of A.21)

<–

200 OK

–

–

10-14

UE and SS complete the activation of the supplementary service and then de-activate it again
(Steps 5-9 of A.21)

–

–

–

–

8.39.3.3 Specific message content

None as fully specified in Annex A.21 and A.22.