inside TS 24.229: Content Part, 15 out of 67

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes" or to "tls-connected", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request, and:

If the maximum number of simultaneously registration flows allowed for the related public user identity for the used UE (i.e. linked to the same private user identity and instance ID) is reached, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with rest of the procedures of this subclause;

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running):

1)

check if the user needs to be re-authenticated.

The S-CSCF may require authentication of the user for any REGISTER request, and shall always require authentication for REGISTER requests received without the "integrity-protected" header field parameter in the Authorization header field set to "yes" or "tls-connected".

If the user needs to be re-authenticated, the S-CSCF shall proceed with the procedures as described for the unprotected REGISTER in subclause 5.4.1.2.1, beginning with step 3). If the user does not need to be re-authenticated, the S-CSCF shall proceed with the following steps in this paragraph; and

2)

check whether a registration expiration interval value is included in the REGISTER request and its value. If the registration expiration interval value indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. If the registration expiration interval value does not indicate zero, the S-CSCF:

if the REGISTER request does not contain a "reg-id" header field parameter and the contact address indicated in the Contact header field was not previously registered, send a 403 (Forbidden) response to the UE; and

3)

check whether the public user identity received in the To header field is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 4B below. Otherwise, the S-CSCF shall:

send a 439 (First Hop Lacks Outbound Support) response to the UE, if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header field does not have an "ob" URI parameter; or
otherwise proceed beginning with step 6 below.

In the case that a timer reg-await-auth is running for this user the S-CSCF shall:

1)

check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match;

2)

stop timer reg-await-auth;

3)

check whether an Authorization header field is included, containing:

the private user identity of the user in the "username" header field parameter;
if the "integrity-protected" header field parameter is set to "yes", the "algorithm" header field parameter set to "AKAv2-SHA-256" or "AKAv1-MD5";
if the "integrity-protected" header field parameter is set to "tls-connected", the "algorithm" header field parameter set to "AKAv2-SHA-256" if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association; and
the authentication challenge response needed for the authentication procedure in the "response" header field parameter.

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge response was included;

4)

check whether the received authentication challenge response and the expected authentication challenge response (calculated by the S-CSCF using XRES and other parameters as described in RFC 3310 when AKAv1 is used or as described in RFC 4169 when AKAv2 is used) match. The XRES parameter was received from the HSS as part of the Authentication Vector. The S-CSCF shall only proceed with the following steps if the challenge response received from the UE and the expected response calculated by the S-CSCF match;

4A)

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 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 if the previous registrations have not expired:

terminate all dialogs, 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;
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

NOTE 2:
The last dialog to be terminated will be the dialog established by the UE subscribing to the reg event package. When sending the NOTIFY request to the UE over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".
delete all information associated with the previously registered public user identities;

NOTE 3:
Contact related to emergency registration is not affected. The S-CSCF is not able to deregister contact related to emergency registration and will not delete it.

4B)

if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header field does not have an "ob" URI parameter, send a 439 (First Hop Lacks Outbound Support) response to the UE;

5)

after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, store the following information in the local data:

the list of public user identities, including the registered own public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities due to the received REGISTER request. Each public user identity is identified as either barred or non-barred;
all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered);
if S-CSCF restoration procedures are supported, the restoration information if received as specified in TS 29.228; and
if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;

6)

update registration bindings:

if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header field parameters contained in the Contact header field and all associated SIP URI parameters, with the exception of the "pub-gruu" and "temp-gruu" header field parameters as specified in RFC 5627, and store information for future use;
if the Contact URI in the Contact header field contains a "bnc" URI parameter, as a network option bind each non-barred registered public user identity to a contact address generated according to the procedures of RFC 6140.

NOTE 5:
It is assumed that when the Contact header field contains a "bnc" parameter, the associated public user identities obtained from the HSS are all of a form compatible with registration procedures as specified in RFC 6140; i.e. the set consists only of distinct public user identities contain global numbers in the international format or wildcarded public user identities representing multiple global numbers in the international format. The S-CSCF procedures for handling the error case where an associated public user identity is incompatible with RFC 6140 is out of scope of this specification.
if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" Contact header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3;
if the Contact header field of the REGISTER request contained a "+sip.instance" and a "reg-id" header field parameter, and the SIP URI in the Path header field inserted by the P-CSCF contained an "ob" SIP URI parameter header field, and:
- if the public user identity has not previously been registered with the same "+sip.instance" and "reg-id" Contact header field parameter values, then create the registration flow in addition to any existing registration flow; or
- if the public user identity has previously been registered with the same "+sip.instance" and "reg-id" header field parameter values, then determine whether the request refreshes or replaces an existing registration flow. If the request:
  1. refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or
  2. replaces the existing registration flow with a new flow, then the S-CSCF shall:
    1. 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
    2. 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;
NOTE 6:
The S-CSCF determines whether this REGISTER request replaces or refreshes an existing registration flow by examining the SIP URI in the Path header field inserted into the request by the P-CSCF (see subclause 5.2.2.1).

NOTE 7:
The way the S-CSCF identifies the dialogs associated with the registration flow being replaced is implementation specific.

NOTE 8:
There might be more than one contact information available for one public user identity.

NOTE 9:
The barred public user identities are not bound to the contact information.

NOTE 10:
Contact related to emergency registration is not affected. S-CSCF is not able deregister contact related to emergency registration and will not delete that.

7)

check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them either to the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) and the contact information that was received in the REGISTER request;

8)

determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;

9)

store the "icid-value" header field parameter received in the P-Charging-Vector header field;

10)

if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

11)

create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "tls-pending", "tls-yes", "ip-assoc-pending", or "ip-assoc-yes", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request, and:

If the maximum number of simultaneously registration flows allowed for the related public user identity for the used UE (i.e. linked to the same private user identity and instance ID) is reached, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with rest of the procedures of this subclause;

In the case that there is no authentication currently ongoing for this user (i.e. no timer reg-await-auth is running):

1)

check if the user needs to be re-authenticated. The S-CSCF may require authentication of the user for any REGISTER request, and shall always require authentication for REGISTER requests received without the "integrity-protected" header field parameter in the Authorization header field set to "tls-yes".

If the user needs to be re-authenticated and the REGISTER did not include an Authorization header field with a digest response, the S-CSCF shall proceed with the authentication procedures as described for the initial REGISTER in subclause 5.4.1.2.1 and subclause 5.4.1.2.1B.

If the user needs to be re-authenticated and the REGISTER included an Authorization header field with a digest response, the S-CSCF shall proceed with the authentication procedures as described for the initial REGISTER in subclause 5.4.1.2.1 and subclause 5.4.1.2.1B and include the "stale" header field parameter with value "true" in the WWW-Authenticate header field.

In the case that a timer reg-await-auth is running for this user the S-CSCF shall:

1)

check if the Call-ID of the request matches with the Call-ID of the 401 (Unauthorized) response which carried the last challenge. The S-CSCF shall only proceed further if the Call-IDs match;

2)

stop timer reg-await-auth;

3)

in the case the algorithm is "SHA2-256", "SHA2-512/256" or "MD5", check the following additional fields:

a "realm" header field parameter matching the "realm" header field parameter in the authentication challenge;
an "algorithm" header field parameter which matches the "algorithm" header field parameter sent in the authentication challenge;
"nonce" header field parameter matching the "nonce" header field parameter in the authentication challenge;
a "cnonce" header field parameter; and
a "nc" header field parameter.

The S-CSCF shall only proceed with the following steps in this paragraph if the authentication challenge response was included;

4)

check whether the received authentication challenge response and the expected authentication challenge response match. The expected response is calculated by the S-CSCF as described in RFC 7616 and RFC 8760 using the H(A1) value provided by the HSS. If the received authentication challenge response and the expected authentication challenge response match, then the UE is considered authenticated. If the UE is considered authenticated, and if the "integrity-protected" header field parameter in the Authorization header field is set to the value "tls-pending" or "tls-yes", then the S-CSCF shall associate the registration with the local state of "tls-protected";

4A)

if the REGISTER request contains the "reg-id" Contact header field parameter and the "outbound" option tag in a Supported header field, but the first URI in the Path header does not have an "ob" URI parameter, send a 439 (First Hop Lacks Outbound Support) response to the UE;

5)

after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, store the following information in the local data:

the list of public user identities, including the registered own public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities due to the received REGISTER request. Each public user identity is identified as either barred or non-barred;
all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered);
if S-CSCF restoration procedures are supported, the restoration information, if received, as specified in TS 29.228; and
if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;

6)

update registration bindings:

if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header field parameters contained in the Contact header field and all associated URI parameters, with the exception of the "pub-gruu" and "temp-gruu" header field parameters as specified in RFC 5627, and store information for future use;
if the Contact URI in the Contact header field contains a "bnc" URI parameter, as a network option bind each non-barred registered public user identity to a contact address as specified in RFC 6140.

NOTE 5:
It is assumed that when the Contact header field contains a "bnc" parameter, the associated public user identities obtained from the HSS are all of a form compatible with registration procedures as specified in RFC 6140; i.e. the set consists only of distinct public user identities contain global numbers in the international format or wildcarded public user identities representing multiple global numbers in the international format. The S-CSCF procedures for handling the error case where an associated public user identity is incompatible with RFC 6140 is out of scope of this specification.
if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" Contact header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3;
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 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 if the previous registrations have not expired:
- terminate all dialogs, 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;
- 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
  
  NOTE 6:
  The last dialog to be terminated will be the dialog established by the UE subscribing to the reg event package. When sending the NOTIFY request to the UE over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".
- delete all information associated with the previously registered public user identities;
NOTE 7:
Contact related to emergency registration is not affected. The S-CSCF is not able to deregister contact related to emergency registration and will not delete it.
if the Contact header field of the REGISTER request contained a "+sip.instance" and a "reg-id" header field parameter, and the SIP URI in the Path header field inserted by the P-CSCF contained an "ob" SIP URI parameter header field, and:
- if the public user identity has not previously been registered with the same "+sip.instance" and "reg-id" Contact header field parameter values, then create the registration flow in addition to any existing registration flow; or
- if the public user identity has previously been registered with the same "+sip.instance" and "reg-id" header field parameter values, then determine whether the request refreshes or replaces an existing registration flow. If the request:
  1. refreshes an existing registration flow, then the S-CSCF shall leave the flow intact; or
  2. replaces the existing registration flow with a new flow, then the S-CSCF shall:
    1. 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
    2. 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; and
store the used nonce as a valid nonce for this registration or registration flow (if multiple registration mechanism is used) for an operator configured duration.

7)

check whether a Path header field was included in the REGISTER request and construct a list of preloaded Route header fields from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them to either the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) and contact information that was received in the REGISTER request;

8)

determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request and bind it either to the respective contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used). Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;

9)

store the "icid-value" header field parameter received in the P-Charging-Vector header field;

10)

if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter; and

11)

create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F. The S-CSCF shall also store the nonce-count value in the received REGISTER request and include an Authentication-Info header field containing the fields described in RFC 7616 and RFC 8760 as follows:

a "nextnonce" header field parameter if the S-CSCF requires a new nonce for subsequent authentication responses from the UE. In that case, the S-CSCF shall consider this nonce as a valid nonce for this registration or registration flow (if multiple registration mechanism is used) for an operator configured duration;
a "qop" header field parameter matching the "qop" Authorization header field parameter sent by the UE;
a "rspauth" header field parameter with a response-digest calculated as described in RFC 7616 and RFC 8760;
a "cnonce" header field parameter matching the "cnonce" Authorization header field parameter sent by the UE; and
a "nc" header field parameter matching the "nc" Authorization header field parameter sent by the UE.

The procedures for subclause 5.4.1.2.2A apply.

There is no protected REGISTER when NASS-IMS bundled authentication is used as a security mechanism. The procedures of subclause 5.4.1.2.1D apply to all REGISTER requests.

There is no protected REGISTER when GPRS-IMS-Bundled authentication is used as a security mechanism. The procedures of subclause 5.4.1.2.1E apply to all REGISTER requests.

The S-CSCF shall not perform authentication of the user for any REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "auth-done".

In this release of this document, when the registration procedure as specified in this subclause is performed, i.e., the REGISTER request contains the "integrity-protected" header field parameter in the Authorization header set to "auth-done", the S-CSCF shall not employ outbound registration as described in RFC 5626.

Upon receipt of a REGISTER request with the "integrity-protected" header field parameter in the Authorization header set to "auth-done", the S-CSCF shall identify the user by the public user identity as received in the To header field and the private user identity as received in the Authorization header field of the REGISTER request.

In addition the S-CSCF shall check whether a registration expiration interval value is included in the REGISTER request and its value. If the registration expiration interval value indicates a zero value, the S-CSCF shall perform the deregistration procedures as described in subclause 5.4.1.4. If the registration expiration interval value does not indicate zero, the S-CSCF shall:

if the REGISTER request contains the "reg-id" header field parameter in the Contact header field, respond with a 403 (Forbidden) response to the REGISTER request; and
if 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 if the previous registrations have not expired:
1. terminate all dialogs, 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
  
  NOTE 1:
  The last dialog to be terminated will be the dialog established by the user (identified with its private user identity) subscribing to its own reg event package using the old contact address. When sending the NOTIFY request over this dialog, the S-CSCF will terminate this dialog by setting in the NOTIFY request the Subscription-State header field to the value of "terminated".
3. delete all information associated with the previously registered public user identities;

Subsequently, the S-CSCF shall check whether the public user identity received in the To header field is already registered. If it is not registered, the S-CSCF shall proceed beginning with step 1 below. Otherwise, the S-CSCF shall proceed beginning with step 2 below.

after performing the S-CSCF Registration/deregistration notification procedure with the HSS, as described in TS 29.228, store the following information in the local data:
1. the list of public user identities, including the registered own public user identity and its associated set of implicitly registered public user identities and wildcarded public user identities due to the received REGISTER request. Each public user identity is identified as either barred or non-barred;
2. all the service profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including initial Filter Criteria(the initial Filter Criteria for the Registered and common parts is stored and the unregistered part is retained for possible use later - in the case of the S-CSCF is retained if the user becomes unregistered); and
3. if PCRF based P-CSCF restoration procedures are supported, all the user profile(s) corresponding to the public user identities being registered (explicitly or implicitly), including the IMSI, if available;
NOTE 2:
There might be more than one set of initial Filter Criteria received because some implicitly registered public user identities that are part of the same implicit registration set belong to different service profiles.
update registration bindings:
1. if the Contact URI in the Contact header field does not contains a "bnc" URI parameter, then bind to each non-barred registered public user identity all registered contact information including all header parameters contained in the Contact header and all associated URI parameters, with the exception of the URI "pub-gruu" and "temp-gruu" parameters as specified in RFC 5627, and store information for future use;
2. if the Contact URI in the Contact header field contains a "bnc" URI parameter, as a network option bind each non-barred registered public user identity to a contact address as specified in RFC 6140.
  
  NOTE 3:
  It is assumed that when the Contact header field contains a "bnc" parameter, the associated public user identities obtained from the HSS are all of a form compatible with registration procedures as specified in RFC 6140; i.e. the set consists only of distinct public user identities contain global numbers in the international format or wildcarded public user identities representing multiple global numbers in the international format. The S-CSCF procedures for handling the error case where an associated public user identity is incompatible with RFC 6140 is out of scope of this specification.
3. if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then for each binding that contains a "+sip.instance" header field parameter, assign a new temporary GRUU, as specified in subclause 5.4.7A.3.
NOTE 4:
There might be more than one contact information available for one public user identity.

NOTE 5:
The barred public user identities are not bound to the contact information.
check whether a Path header was included in the REGISTER request and construct a list of preloaded Route headers from the list of entries in the received Path header field. The S-CSCF shall preserve the order of the preloaded Route header fields and bind them to the contact information that was received in the REGISTER request;

NOTE 6:
If this registration is a reregistration or an initial registration (i.e., there are previously registered public user identities belonging to the user that have not been deregistered or expired), then a list of pre-loaded Route headers will already exist. The new list replaces the old list.
determine the duration of the registration by checking the value of the registration expiration interval value in the received REGISTER request. Based on local policy, the S-CSCF may reduce the duration of the registration or send back a 423 (Interval Too Brief) response specifying the minimum allowed time for registration. The local policy can take into account specific criteria such as the used authentication mechanism to determine the allowed registration duration;
store the "icid-value" header field parameter received in the P-Charging-Vector header;
if an "orig-ioi" header field parameter is received in the P-Charging-Vector header, store the value of the received "orig-ioi" header field parameter; and

NOTE 7:
Any received "orig-ioi" header field parameter will be a type 1 IOI. The type 1 IOI identifies the network from which the request was sent.
create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.

If a 200 (OK) response is to be sent for a REGISTER request, the S-CSCF shall, in addition to any contents identified elsewhere in subclause 5.4.1.2, include:

a)

the list of received Path header fields;

b)

a P-Associated-URI header field containing the list of the registered distinct public user identity and its associated set of implicitly registered distinct public user identities. The first URI in the list of public user identities supplied by the HSS to the S-CSCF will indicate the default public user identity to be used by the S-CSCF. The public user identity indicated as the default public user identity must be a registered public user identity. The S-CSCF shall place the default public user identity as the first entry in the list of URIs present in the P-Associated-URI header field. The default public user identity will be used by the P-CSCF in conjunction with the procedures for the P-Asserted-Identity header field, as described in subclause 5.2.6.3. If the S-CSCF received a display name from the HSS for a public user identity, then the S-CSCF shall populate the P-Associated-URI header field entry for that public identity with the associated display name. The S-CSCF shall not add a barred public user identity to the list of URIs in the P-Associated-URI header field;

c)

a Service-Route header field containing:

the SIP URI identifying the S-CSCF containing an indication that subsequent requests routed via this service route (i.e. from the P-CSCF to the S-CSCF) was sent by the UE using either the contact address of the UE or the registration flow and the associated contact address (if the multiple registration mechanism is used) that has been registered and are treated as for the UE-originating case.

NOTE 2:
This indication can e.g. be in a parameter in the URI, a character string in the user part of the URI or be a port number in the URI.

The S-CSCF shall use a different SIP URI for each registration. If the multiple registration mechanism is used, the S-CSCF shall also use a different SIP URI for each registration flow associated with the registration;
if network topology hiding is required a SIP URI identifying an IBCF as the topmost entry; and

NOTE 3:
In accordance with the procedures described in RFC 3608, an IBCF does not insert its own routable SIP URI to the Service-Route header field.
if
1. S-CSCF supports indicating the traffic leg associated with a URI as specified in RFC 7549;
2. the UE is roaming;
3. the P-CSCF is not in the home network; and
4. required by local policy
then the S-CSCF may append an "iotl" SIP URI parameter with a value set to "visitedA-homeA" to the S-CSCF SIP URI in the Service-Route header field;

d)

if the P-CSCF is in the same network as the S-CSCF a P-Charging-Function-Addresses header field containing the values received from the HSS. It can be determined if the P-CSCF is in the same network as the S-CSCF by the contents of the P-Visited-Network-ID header field included in the REGISTER request;

e)

a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 1 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request;

f)

a Contact header field listing all contact addresses for this public user identity, including all saved header field parameters and URI parameters (including all ICSI values and IARI values) received in the Contact header field of the REGISTER request,

g)

GRUUs in the Contact header field. If the REGISTER request contained a Required or Supported header field containing the value "gruu" then for each contact address in the Contact header field that has a "+sip.instance" header field parameter:

add "pub-gruu" header field parameter containing the public GRUU representing (as specified in subclause 5.4.7A.2) the association between the public user identity from the To header field in the REGISTER request and the instance ID contained in the "+sip.instance" header field parameter;
if the Contact URI in the Contact header field does not contain a "bnc" URI parameter, then add a "temp-gruu" header field parameters. containing the most recently assigned temporary GRUU representing (as specified in subclause 5.4.7A) the association between the public user identity from the To header field in the REGISTER request and the instance ID contained in the "+sip.instance" header field parameter; and
if the S-CSCF supports RFC 6140 and the Contact URI in the Contact header field contains a "bnc" URI parameter, then add a "temp-gruu-cookie" header field parameter containing a value generated as specified in RFC 6140;

h)

if the received REGISTER request contained both a "reg-id" and "+sip.instance" header field parameters in the Contact header field, and the first URI within the Path header field contains the "ob" SIP URI parameter a Require header field with the "outbound" option-tag as described in RFC 5626;

i)

void

j)

optionally, a Feature-Caps header field including the ICSI values contained in the service profile of the served user except the ones that require explicit support indication of capabilities by intermediary entities and that have not been indicated as supported according to RFC 6809 for the corresponding registration or registration flow (if multiple registration mechanism is used);

k)

if the home network supports calling number verification using signature verification and attestation information, as defined in subclause 3.1,a Feature-Caps header field, as specified in RFC 6809, including the "+g.3gpp.verstat" header field parameter;

l)

if the home network supports the response code 607 (Unwanted) as specified in RFC 8197, a Feature-Caps header field including the "+sip.607" header field parameter; and

m)

if the home network supports the data channel, a Feature-Caps header field, as specified in clause B.1.1 of 3GPP TS 24.186 [297], including the "+g.3gpp.datachannel" header field parameter.

and send the so created 200 (OK) response to the UE.

For all service profiles in the implicit registration set, the S-CSCF shall send a third-party REGISTER request, as described in subclause 5.4.1.7, to each AS that matches the Filter Criteria of the service profile from the HSS for the REGISTER event; and,

The S-CSCF shall consider the public user identity being registered to be bound either to the contact address of the UE or to the registration flow and the associated contact address (if the multiple registration mechanism is used), as specified in the Contact header field, for the duration indicated in the registration expiration interval value.

In the case that the expiration timer from the UE is too short to be accepted by the S-CSCF, the S-CSCF shall:

reject the REGISTER request with a 423 (Interval Too Brief) response, containing a Min-Expires header field with the minimum registration time the S-CSCF will accept.

On receiving a failure response to one of the third-party REGISTER requests, based on the information in the Filter Criteria the S-CSCF may:

abort sending third-party REGISTER requests; and
initiate network-initiated deregistration procedure.

If the Filter Criteria does not contain instruction to the S-CSCF regarding the failure of the contact to the AS, the S-CSCF shall not initiate network-initiated deregistration procedure.

In the case that the REGISTER request from the UE contains multiple SIP URIs which are different addresses as Contact header field entries, the S-CSCF shall store:

the entry in the Contact header field with the highest value of the "q" header field parameter; or
an entry decided by the S-CSCF based on local policy;

and include the stored entry in the 200 (OK) response.

In the case that the REGISTER request from the UE contains multiple SIP URIs which are the same addresses with the same value of the "q" Contact header field parameter, the S-CSCF shall not store multiple entries with the same "q" value but store one of the entries with the same "q" value based on local policy along with any entries that have different "q" values and include only the stored entries in the 200 (OK) response.

If the S-CSCF receives a new initial REGISTER request before the reg-await-auth timer expires, the S-CSCF shall:

stop the reg-await-auth timer; and
initiate the authentication procedures for initial registration as if there is no authentication currently ongoing for this user and send a 401 (Unauthorized) response containing a new challenge as described in subclause 5.4.1.

For any error response, the S-CSCF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the REGISTER request, a type 1 "term-ioi" header field parameter and the "icid-value" header field parameter. The S-CSCF shall set the type 1 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request.

If the Contact header field in the REGISTER request from the UE contains an invalid Contact URI as defined in RFC 6140 (e.g., the Contact URI contains both a "bnc" and "user" URI parameter) then the S-CSCF shall reject the REGISTER request with a 400 (Bad Request) response.

In the case that the REGISTER request, that contains the authentication challenge response from the UE does not match with the expected REGISTER request (e.g. wrong Call-Id or authentication challenge response) and the request has the "integrity-protected" header field parameter in the Authorization header field set to "yes", the S-CSCF shall:

send a 403 (Forbidden) response to the UE. The S-CSCF shall consider this authentication attempt as failed. The S-CSCF shall not update the registration state of the subscriber.

In the case that the REGISTER request from the UE containing an "auts" Authorization header field parameter, indicating that the SQN was deemed to be out of range by the UE), the S-CSCF will fetch new authentication vectors from the HSS. In order to indicate a resynchronisation, the S-CSCF shall include the value of the "auts" header field parameter received from the UE and the stored RAND, when fetching the new authentication vectors. On receipt of the new authentication vectors from the HSS, the S-CSCF shall either:

send a 401 (Unauthorized) response to initiate a further authentication attempt, using these new vectors; or
respond with a 403 (Forbidden) response if the authentication attempt is to be abandoned. The S-CSCF shall not update the registration state of the subscriber.

In the case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "yes", for which the public user identity received in the To header field and the private user identity received in the "username" Authorization header field parameter of the REGISTER request do not match to any registered user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as described in subclause 5.4.1.2.2, otherwise the S-CSCF shall:

respond with a 500 (Server Internal Error) response to the UE.

In the case that the REGISTER request, that contains the authentication challenge response from the UE does not match with the expected REGISTER request (e.g. wrong Call-Id or authentication challenge response) and the request has the "integrity-protected" header field parameter in the Authorization header field set to either "tls-pending", "tls-yes", "ip-assoc-pending", or "ip-assoc-yes", the S-CSCF shall do one of the following:

send a 403 (Forbidden) response to the UE. The S-CSCF shall consider this authentication attempt as failed. The S-CSCF shall not update the registration state of the subscriber; or
rechallenge the user by issuing a 401 (Unauthorized) response including a challenge as per the authentication procedures described in subclause 5.4.1.2.1B.

In the case that the REGISTER request from the UE contains an invalid "nonce" Authorization header field parameter with a valid challenge response for that nonce (indicating that the client knows the correct username/password), or when the nonce-count value sent by the UE is not the expected value, the S-CSCF shall:

send a 401 (Unauthorized) response to initiate a further authentication attempt with a fresh nonce and the "stale" header field parameter set to "true" in the WWW-Authenticate header field.

In the case that the S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "tls-pending", "tls-yes", "ip-assoc-pending", or "ip-assoc-yes", for which the public user identity received in the To header field and the private user identity received in the Authorization header field of the REGISTER request do not match to any registered or initial registration pending user at this S-CSCF, if the S-CSCF supports S-CSCF restoration procedures, the S-CSCF shall behave as described in subclause 5.4.1.2.2A, otherwise the S-CSCF shall:

respond with a 500 (Server Internal Error) response to the UE.

The procedures for subclause 5.4.1.2.3B apply.

There are no abnormal cases for NASS-IMS bundled authentication.

There are no abnormal cases for GPRS-IMS-Bundled authentication.

Content for TS 24.229 Word version: 18.4.0

5.4.1.2.2 Protected REGISTER with IMS AKA as a security mechanism p. 242

5.4.1.2.2A Protected REGISTER with SIP digest as a security mechanism |R8| p. 245

5.4.1.2.2B Protected REGISTER with SIP digest with TLS as a security mechanism |R8| p. 248

5.4.1.2.2C NASS-IMS bundled authentication as a security mechanism |R8| p. 248

5.4.1.2.2D GPRS-IMS-Bundled authentication as a security mechanism |R8| p. 248

5.4.1.2.2E Protected REGISTER - Authentication already performed |R8| p. 249

5.4.1.2.2F Successful registration |R8| p. 250

5.4.1.2.3 Abnormal cases - general p. 252

5.4.1.2.3A Abnormal cases - IMS AKA as security mechanism |R8| p. 253

5.4.1.2.3B Abnormal cases - SIP digest as security mechanism |R8| p. 254

5.4.1.2.3C Abnormal cases - SIP digest with TLS as security mechanism |R8| p. 255

5.4.1.2.3D Abnormal cases - NASS-IMS bundled authentication as security mechanism |R8| p. 255

5.4.1.2.3E Abnormal cases - GPRS-IMS-Bundled authentication as security mechanism |R8| p. 255