8.1 Originating Identification Presentation / Configuration / 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.1.1 Test Purpose (TP)

(1)

with { UE being registered to IMS }

ensure that {

when { UE is made to activate OIP }

then { UE authenticates itself using Digest or GBA }

}

(2)

with { UE having started authentication using Digest or GBA }

ensure that {

when { UE receives 200 OK concluding the authentication }

then { UE sends HTTP request to activate OIP }

}

(3)

with { UE having concluded activation of OIP }

ensure that {

when { UE is made to de-activate OIP }

then { UE sends HTTP request to de-activate OIP }

}

8.1.2 Conformance Requirements

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

Generic requirements for Originating Identification Presentation can be found from TS 34.229-1 Annexes F.1 and F.2.

[TS 24.607, clause 4.2.1]:

The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network provided) identity information in order to identify the originating user.

In addition to the trusted identity information, the identity information from the originating user can include identity information generated by the originating user and in general transparently transported by the network. In the particular case where the "no screening" special arrangement does not apply, the originating network shall verify the content of this user generated identity information. The terminating network cannot be responsible for the content of this user generated identity information.

[TS 24.607 clause 4.10.1]:

The OIP service can be activated/deactivated using the active attribute of the <originating‑identity‑presentation> service element.

[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.1.3 Test description

8.1.3.1 Pre-test conditions

System Simulator:

– SS is configured with shared secret key of IMS AKA algorithm, related to the IMS private user identity (IMPI) configured on the UICC card equipped into the UE.

– SS is listening to SIP default port 5060 for both UDP and TCP protocols.

– At the SS, a HTTP Server is established at port 80 to simulate the XCAP server

– 1 NR Cell

UE:

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

– UE is configured with the name of the XCAP root directory on the XCAP server and the user’s directory name.

– UE has activated an IPCAN bearer with SS.

Preamble:

– The steps 0a and 0b of Annex A.21 have been executed

– During these procedures the UE may request a DNS server address via NAS signalling and as parallel behaviour the UE may resolve the IP address of the XCAP server via DNS.

8.1.3.2 Test procedure sequence

Table 8.1.3.2-1: Main Behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE is triggered for activation of supplementary service OIP

–

–

–

–

2-5b

Check: Does the UE perform steps 2-5b of the generic test procedure for activation of Supplementary Services according to annex A.21

–

–

1

–

6

Check: Does the Simservs document stored in the SS contain the information supplied by UE as according to table 8.1.3.3-2?

-<originating-identity-presentation> element with "active" attribute being set "true"

–

–

2

P

7

Make the UE attempt deactivation of OIP

–

–

–

–

8-8b

Check: Does the UE perform steps 8-8b of the generic test procedure for activation of Supplementary Services according to annex A.21?

–

–

3

–

9

Check: Does the Simservs document stored in the SS contain the information supplied by UE as according to table 8.1.3.3-3?

–

–

3

P

8.1.3.3 Specific message contents

Table 8.1.3.3-1: Simservs document (step 4)

Derivation Path: TS 24.607 clause 4.10.2

Content

Comment

<simservs>

<originating-identity-presentation active="false">

</simservs>

Table 8.1.3.3-2: Simservs document (step 6)

Derivation Path: TS 24.607 clause 4.10.2

Content

Comment

<simservs>

<originating-identity-presentation active="true">

The “active” attribute may not be present but if present is is set to “true”.

</simservs>

Table 8.1.3.3-3: Simservs document (step 9)

Derivation Path: TS 24.607 clause 4.10.2

Content

Comment

<simservs>

<originating-identity-presentation active="false">

</simservs>