P.3 P‑CSCF procedure selection

33.2033G Security3GPPAccess security for IP-based servicesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

When the P‑CSCF receives a registration request it shall proceed as follows:

The P CSCF first checks for the presence of an Authorization header in the REGISTER request, and, if present, checks further for the presence of an "integrity-protected" flag within this header. If the flag is present in the message from the UE, it shall be removed.

The P‑CSCF shall then check whether the Security-Client header exists in the received REGISTER message:

If the REGISTER request contains a Security-Client header then, for an initial registration, the P-CSCF shall select the sec-mechanism and mode (cf. Annex H) from the corresponding parameters offered in the Security-Client header according to its priorities.

– If the P-CSCF selects the sec-mechanism "ipsec-3GPP" and the mode "trans" it shall perform the steps required for IMS AKA without NAT traversal.

– If the P-CSCF selects the sec-mechanism "ipsec-3GPP" and the mode "UDP-enc-tun" it shall perform the steps required for IMS AKA with NAT traversal.

– If the P-CSCF selects the sec-mechanism "tls" it shall perform the steps required for SIP Digest with TLS.

If the REGISTER request does not contain a Security-Client header, or the P-CSCF does not select any sec-mechanism from the Security-Client header, then the P-CSCF shall behave as follows:

– If the REGISTER request contains an Authorization header signalling an algorithm "AKAv2-SHA-256", then the eP-CSCF shall perform the step required for IMS AKA with HTTP Digest AKAv2 over TLS session set-up prior to registration as defined for WebRTC over IMS. The eP-CSCF forwards the REGISTER request to the S-CSCF including the "integrity-protected" header field parameter with the value set to "tls-connected".

– Otherwise:

– If the REGISTER request is received over a TLS connection, the P-CSCF shall perform the steps required for Digest with TLS prior to Initial registration according to Clause O.2.3.

– Otherwise

If the REGISTER request does not contain an Authorization header and was received over an access networks defined in 3GPP specifications then the P‑CSCF shall perform the steps required for GIBA.

If the REGISTER request was not received over a TISPAN NASS or 3GPP network then the P‑CSCF shall perform the steps required for SIP Digest without TLS.

If the REGISTER request was received over a TISPAN NASS access, then the P‑CSCF shall perform the steps required for NBA as well as the steps required for SIP Digest without TLS, unless it is configured to behave differently or the P-CSCF only supports either SIP Digest without TLS or NBA. If the NBA-related query from the P-CSCF to the TISPAN NASS fails the P-CSCF shall not continue to perform the NBA-related steps.

- For a subsequent registration, the P-CSCF shall continue to use the selected mechanism.

NOTE 1: Note that Annex N states that SIP Digest authentication shall not apply to access networks defined in 3GPP specifications.

NOTE 2: The use of Authorization headers in IMS REGISTER requests is defined in TS 24.229 [8].

NOTE 3: The inclusion of an Authorization header in a REGISTER request is optional for NBA and optional for SIP Digest. Therefore, when a REGISTER request is received over a TISPAN NASS the P-CSCF cannot know whether the request relates to SIP Digest or NBA unless it is configured to select one of the schemes according to certain criteria, e.g. IP address range. The steps required for SIP Digest and for NBA are not in contradiction. Rather, for NBA the P-CSCF needs to perform additional steps, namely an exchange with the TISPAN NASS and an inclusion of NASS location information in the REGISTER request, on top of the steps required for SIP Digest.

A P-CSCF is said to be “PANI-aware” if it handles P-Access-Network-Info headers as follows:

- A “PANI-aware” P‑CSCF shall insert a P-Access-Network-Info header containing the "network-provided" parameter and remove any such header containing the "network-provided" parameter sent by the UE if the REGISTER request was received over a TISPAN NASS.
- A “PANI-aware” P‑CSCF may insert a P-Access-Network-Info header containing the "network-provided" parameter and shall remove any such header containing the "network-provided" parameter sent by the UE if the REGISTER request was not received over a TISPAN NASS.

P-Access-Network-Info headers are used by the S-CSCF to distinguish REGISTER requests relating to GIBA from REGISTER requests relating to NBA and SIP Digest, which do not necessarily use an Authorization header in the initial REGISTER request, cf. Annex P.4.2 of this specification. This motivates the following rule:

- Under the additional conditions that the REGISTER request contains no Authorization header and was received over an access network other than TISPAN NASS or 3GPP it is even mandatory for the P‑CSCF to insert a P-Access-Network-Info header containing the "network-provided" parameter.

NOTE 4: For the purposes of NBA, the P-CSCF includes NASS location information in the P-Access-Network-Info header. But, according to TS 24.229 [8], the P‑CSCF handles any P-Access-Network-Info header included by the UE transparently, and, hence, an S‑CSCF could receive a P-Access-Network-Info header with false NASS location information inserted by the UE even when the access network is not a TISPAN NASS. This would negatively impact the security of NASS-IMS-bundled authentication. Therefore, the removal of a P-Access-Network-Info header with the "network-provided" parameter is mandated for PANI-aware P-CSCFs even when the access network is not a TISPAN NASS.

How the P‑CSCF knows the access network type of a specific network interface is implementation-dependent (e.g. it can know the access network type from different UE IP address ranges or by using different network interfaces for different access network types).

NOTE 5: The P-CSCF is not in the path for all authentication techniques. For example, for TNA the Trusted Node communicates directly with the I-CSCF.