P.4 Determination of requested authentication scheme in S‑CSCF

33.2033G Security3GPPAccess security for IP-based servicesTS

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

P.4.1 Stepwise approach

When receiving a REGISTER request the S‑CSCF distinguishes among authentication methods using the following three steps. How these steps are performed is described in subclause P.4.2.

– Step 1: the S‑CSCF first checks whether the IMS REGISTER request relates to IMS AKA or not. In the case of IMS AKA, the S‑CSCF shall behave according to this specification. Otherwise, the S‑CSCF proceeds to step 1a.

– Step 1a: the S-CSCF checks whether the IMS REGISTER request relates to TNA or not. In the case of TNA, the S-CSCF shall behave according to Annex U of this specification. Otherwise, the S-CSCF proceeds to step 2.

– Step 2: for a non-IMS-AKA REGISTER request, the S‑CSCF next checks whether the request relates to GIBA. In the case of GIBA the S‑CSCF shall behave according to Annex T of this specification. Otherwise, the S‑CSCF proceeds to step 3.

– Step 3: In step 3, the S‑CSCF requests the HSS to perform the distinction among SIP Digest and NBA.

NOTE_p6: The distinctions in steps 1 and 2 are required because the records of an IMS AKA or GIBA user may reside on an HSS of an earlier release. Such an HSS requires the authentication scheme to be determined by the S-CSCF according to the specification for IMS AKA and GIBA.

For subsequent REGISTER requests, the authentication scheme shall not change.

P.4.2 Mechanisms for performing steps 1 to 3 in P.4.1

Step 1:

The S‑CSCF 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 and has either the value “yes” or the value “no” the S‑CSCF concludes that the REGISTER request relates to IMS AKA. If the value of the "integrity-protected" flag is set to "tls-connected" and "algorithm" parameter in the Authorization header has the value "AKAv2-SHA-256", then the S-CSCF concludes that the REGISTER request relates to IMS AKA with HTTP Digest AKAv2 over TLS session set-up prior to registration, as defined for WebRTC over IMS in Annex X.

NOTE 1: the "integrity-protected" flag and its values are defined in TS 24.229 [8].

Step 1a:

The S-CSCF 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 and has the value "auth-done" the S-CSCF concludes that the REGISTER request related to TNA.

Step 2:

The S‑CSCF then shall proceed as follows:

If there is no Authorization header in the REGISTER request, and there is either no P-Access-Network-Info header containing the "network-provided" parameter, or there is a P-Access-Network-Info header containing the "network-provided" parameter, in which the access-type parameter indicates 3GPP, and the S-CSCF supports GIBA then GIBA is used.

Otherwise, the S‑CSCF proceeds to step 3.

NOTE 2: P-Access-Network-Info headers not containing the "network-provided" parameter are irrelevant for the above condition.

NOTE 3: If an S-CSCF supports both, GIBA and SIP Digest without Authorization header in the initial REGISTER message, then the mechanism described in this step works properly only if the P-CSCF inserts PANI headers as described in Annex P.3 of this specification.

Step 3:

This step rests on three conditions:

1) The S‑CSCF shall know, e.g. using the mechanism in clause P.5, which P‑CSCFs in the home network are PANI-aware in the sense of clause P.3.

2) It shall be ensured that P‑CSCFs in the home network, which are not PANI-aware, do not connect to TISPAN NASS.

3) A user always uses either NBA or SIP Digest, but not sometimes NBA and sometimes SIP Digest.

If the S-CSCF supports both SIP Digest and NBA, the S‑CSCF shall send an authentication request to the HSS indicating that the authentication scheme is unknown. The S-CSCF shall infer the authentication scheme used by the subscriber from authentication request response by the HSS.

If the returned authentication scheme is NBA the S-CSCF shall proceed with this authentication only if the P‑CSCF is in the home network and “PANI-aware”.

If the returned authentication scheme is SIP Digest the S-CSCF will learn from the "integrity-protected" flag in the subsequently received REGISTER request containing the challenge response whether SIP Digest with or without TLS is used.

If the S-CSCF supports NBA but not SIP Digest, the S-CSCF shall send an authentication request to the HSS indicating that the authentication scheme is either NBA or unknown. The S-CSCF shall infer the authentication scheme used by the subscriber from authentication request response by the HSS. If the returned authentication scheme is NBA the S-CSCF shall proceed with this authentication only if the P CSCF is in the home network and “PANI-aware”.

If the S-CSCF supports SIP Digest but not NBA, the S-CSCF shall send an authentication request to the HSS indicating that the authentication scheme is either SIP digest or unknown. The S-CSCF shall infer the authentication scheme used by the subscriber from authentication request response by the HSS. If the returned authentication scheme is SIP Digest the S-CSCF will learn from the "integrity-protected" flag in the subsequently received REGISTER request containing the challenge response whether SIP Digest with or without TLS is used.