Content for  TS 24.229  Word version:  18.4.0

Any REGISTER request received unprotected by the S-CSCF without an Authorization header field, or with an Authorization header field having the "integrity-protected" header field parameter in the Authorization header field set to "no", or without an "integrity-protected" header field parameter is considered to be an initial registration. If such an initial registration contains a private user identity specifically reserved for IM CN subsystem registrations from an MSC Server enhanced for ICS as defined in TS 23.003, the S-CSCF shall respond with a 403 (Forbidden) response. The S-CSCF shall consider this registration attempt as failed. Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity for which the maximum number of allowed simultaneously registration flows for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause. Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a user identity linked to a private user identity and instance ID/reg-id if available, that has previously registered one or more public user identities, the S-CSCF shall:

1. perform the procedure below in this subclause for receipt of a REGISTER request for a public user identity which is not already registered, for the received public user identity;
2. if the multiple registrations is not used and if the authentication that in step 1) has been successful, and there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request, and the previous registrations have not expired, perform the network-initiated deregistration procedure (as described in subclause 5.4.1.5) for the previously registered public user identities belonging to this user including the public user identity being registered, if previously registered; and
3. if the multiple registrations is used (i.e., the "reg-id" header field parameter is included in the REGISTER request), and if the authentication that concludes the initial registration has been successful, and if the public user identity being registered has been previously registered with the same private user identity and the same "+sip.instance" and "reg-id" header field parameter values, and the previous registration has not expired:
   1. identify the registration flow being replaced;
   2. terminate any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, associated with the registration flow being replaced; and
   3. send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2.

When S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "no" and a non-empty "response" Authorization header field parameter, the S-CSCF shall ignore the value of the "response" header field parameter. Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity which is not already registered linked to the same private user identity and the "+sip.instance" and "reg-id" header field parameters, if available, the S-CSCF shall:

1. identify the user by the public user identity as received in the To header field and if the REGISTER request includes an Authorization header field, identify the private user identity as received in the "username" Authorization header field parameter of the REGISTER request;
2. check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;
3. select an authentication vector for the user. If no authentication vector for this user is available, after the S-CSCF has performed the Authentication procedure with the HSS, as described in TS 29.228, the S-CSCF shall select an authentication vector as described in TS 33.203.
   Prior to performing Authentication procedure with the HSS, the S-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228 or use the value as received in the P-User-Database header field in the REGISTER request as defined in RFC 4457;
4. store the "icid-value" header field parameter received in the P-Charging-Vector header field;
5. challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request appropriate to the security mechanism in use;
6. send the so generated 401 (Unauthorized) response towards the UE, and if the URI in the first Path header field has an "ob" SIP URI parameter, include a Require header field with the option-tag "outbound" as described in RFC 5626; and
7. start timer reg-await-auth which guards the receipt of the next REGISTER request.

If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was deemed to be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in the subclause 5.4.1.2.3.

On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:

1. a WWW-Authenticate header field which transports:
   1. a globally unique name of the S-CSCF in the "realm" header field parameter;
   2. the RAND and AUTN parameters and optional server specific data for the UE in the "nonce" header field parameter;
   3. if the REGISTER request contains an Authorization header field with an "integrity-protected" header field parameter set to the value "no":
      • the security mechanism, in the "algorithm" header field parameter set to the value as received in the Authorization header field i.e. "AKAv2-SHA-256" or "AKAv1-MD5";
      • the IK (Integrity Key) parameter for the P-CSCF in the "ik" header field parameter (see subclause 7.2A.1); and
      • the CK (Cipher Key) parameter for the P-CSCF in the "ck" header field parameter (see subclause 7.2A.1); and
   4. if the REGISTER request does contain an Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association:
      • the security mechanism, which is "AKAv2-SHA-256" in the "algorithm" header field parameter.

The S-CSCF shall store the RAND parameter used in the 401 (Unathorized) response for future use in case of a resynchronisation. If a stored RAND already exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND used in the most recent 401 (Unauthorized) response.

On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:

1. for each supported digest algorithm the S-CSCF shall create a WWW-Authenticate header field as defined in RFC 7616 and RFC 8760, which transports:
   • a protection domain in the "realm" header field parameter;
   • a "nonce" header field parameter (generated by the S-CSCF);
   • an "algorithm" header field parameter; and
   • a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall contain the value "auth".
   The S-CSCF shall include the WWW-Authenticate header fields to the 401 (Unauthorized) response in order of preference, starting with the most preferred algorithm.

The procedures for subclause 5.4.1.2.1B apply.

Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a user identity linked to a private user identity that has a registered public user identity but with a new contact address, the S-CSCF shall:

1. perform the procedure for receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without the Authorization header field, for the received public user identity; and
2. if the Contact header field of the REGISTER request does not contain a "reg-id" header field parameter (i.e., the multiple registrations mechanism is not used), and the authentication has been successful, and there are public user identities (including the public user identity being registered, if previously registered) belonging to this user that have been previously registered with the same private user identity and with an old contact address different from the one received in the REGISTER request and if the previous registration have not expired:
   1. terminate all dialogs, if any, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
   2. send a NOTIFY request, to the subscribers to the registration event package of the previously registered public user identities, that indicates that all previously registered public user identities (excluding the public user identity being registered) belonging to this user identified with its private user identity, have been deregistered, as described in subclause 5.4.2.1.2. For the public user identity being registered, the NOTIFY request contains the new contact information; and
   3. delete all information associated with the previously registered public user identities.

Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a public user identity for which the maximum number of allowed simultaneously registration flows is for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause; Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, which is not for an already registered public user identity linked to the same private user identity, the S-CSCF shall:

1. identify the user by the public user identity as received in the To header field of the REGISTER request and if the Authorization header field is present, the private user identity as received in the Authorization header field of the REGISTER request. If the Authorization header field is not present, the S-CSCF shall derive the private user identity from the public user identity being registered by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters;
2. check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a Authentication procedure with the HSS, are available for the user. If not, the S-CSCF performs the Authentication procedure with the HSS, as described in TS 29.228, in order to obtain these Line-Identifiers;
3. in the particular case where the S-CSCF received via the Cx interface one or more Line-Identifiers, compare each of Line-Identifiers with the "dsl-location", "eth-location" or "fiber-location" parameter of the P-Access-Network-Info header field (if present and if it includes the "network-provided" parameter):
   • if one of these match, the user is considered authenticated, behave as described in step 5) to 11) of subclause 5.4.1.2.2;
   • otherwise i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER request; and
4. if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the REGISTER request.

Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, for an already registered public user identity linked to the same private user identity, and for existing contact information, the S-CSCF shall behave as described in subclause 5.4.1.2.2F.

Upon receipt of a REGISTER request without an Authorization header field, the S-CSCF shall: When a user de-registers, or is de-registered by the HSS, the S-CSCF shall delete the IP address stored for the UE.