Content for  TS 24.229  Word version:  19.0.0

The UE can perform the reregistration of a previously registered public user identity bound to any one of its contact addresses and the associated set of security associations or TLS sessions at any time after the initial registration has been completed. The UE can perform the reregistration of a previously registered public user identity over any existing set of security associations or TLS session that is associated with the related contact address. The UE can perform the reregistration of a previously registered public user identity via an initial registration as specified in subclause 5.1.1.2, when binding the previously registered public user identity to new contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used). The UE can perform registration of additional public user identities at any time after the initial registration has been completed. The UE shall perform the registration of additional public user identities either:

• over the existing set of security associations or TLS sessions, if appropriate to the security mechanism in use, that is associated with the related contact address; or
• via an initial registration as specified in subclause 5.1.1.2.

The UE can fetch bindings as defined in RFC 3261 at any time after the initial registration has been completed. The procedure for fetching bindings is the same as for a reregistration except that the REGISTER request does not contain a Contact header field. Unless either the user or the application within the UE has determined that a continued registration is not required the UE shall reregister an already registered public user identity either 600 seconds before the expiration time if the previous registration was for greater than 1200 seconds, or when half of the time has expired if the previous registration was for 1200 seconds or less, or when the UE intends to update its capabilities according to RFC 3840 and RFC 5688 or when the UE needs to modify the ICSI values that the UE intends to use in a g.3gpp.icsi-ref media feature tag or IARI values that the UE intends to use in the g.3gpp.iari-ref media feature tag. When sending a protected REGISTER request, the UE shall use a security association or TLS session associated either with the contact address or with the registration flow and the associated contact address used to send the request, see TS 33.203, established as a result of an earlier initial registration. The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. On sending a REGISTER request that does not contain a challenge response, the UE shall populate the header fields as follows:

1. a From header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be registered;
2. a To header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be registered;
3. a Contact header field set to include SIP URI(s) that contain(s) in the hostport parameter the IP address or FQDN of the UE, and containing the instance ID of the UE in the "+sip.instance" header field parameter, if the UE:
   1. supports GRUU (see Table A.4, item A.4/53);
   2. supports multiple registrations;
   3. has an IMEI available; or
   4. has an MEID available.
   Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks.
   If the UE support multiple registrations, it shall include "reg-id" header field as described in RFC 5626. The UE shall include all supported ICSI values (coded as specified in subclause 7.2A.8.2) in a g.3gpp.icsi-ref media feature tag as defined in subclause 7.9.2 and RFC 3840 for the IMS communication it intends to use, and IARI values (coded as specified in subclause 7.2A.9.2), for the IMS applications it intends to use in a g.3gpp.iari-ref media feature tag as defined in subclause 7.9.3 and RFC 3840.
   If the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter.
   If a user part has previously been included in an initial REGISTER request, the UE shall use the user part which was previously used to create the binding being refreshed or removed;
4. a Via header field set to include the IP address or FQDN of the UE in the sent-by field. For the TCP, the response is received on the TCP connection on which the request was sent. If the UE previously has previously negotiated sending of keep-alives associated with the registration, it shall include a "keep" header field parameter with no value in the Via header field, in order to indicate continuous support to send keep-alives, as described in RFC 6223;
5. a registration expiration interval value, set to 600 000 seconds as the value desired for the duration of the registration;
6. a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;
7. the Supported header field containing the option-tag "path", and:
   1. if GRUU is supported, the option-tag "gruu"; and
   2. if multiple registrations is supported, the option-tag "outbound";
8. if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);
9. a Security-Client header field to announce the media plane security mechanisms the UE supports, if any, labelled with the "mediasec" header field parameter specified in subclause 7.2A.7;
10. if the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and
11. if the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

On receiving the 200 (OK) response to the REGISTER request, the UE shall:

1. bind the new expiration time of the registration for this public user identity found in the To header field value either to the contact address or to the registration flow and the associated contact address used in this registration;
2. store the list of service route values contained in the Service-Route header field and bind the list either to the contact address or to the registration flow and the associated contact address (if the multiple registration mechanism is used);
3. if the UE indicated support for GRUU in the Supported header field of the REGISTER request then:
   • if the UE did not use the procedures specified in RFC 6140 for registration find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter or a "temp-gruu" header field parameter or both, then store the value of those parameters as the GRUUs for the UE in association with the public user identity and the contact address that was registered; and
   • if the UE used the procedures specified in RFC 6140 for registration then find the Contact header field within the response that matches the one included in the REGISTER request. If this contains a "pub-gruu" header field parameter then store the value of the "pub-gruu" header field parameter for use for generating public GRUUs for registering UAs as specified in RFC 6140. If this contains a "temp-gruu-cookie" header field parameter then store the value of the "temp-gruu-cookie" header field parameter for use for generating temporary GRUUs for registering UAs as specified in RFC 6140;
4. store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field and labelled with the "mediasec" header field parameter specified in subclause 7.2A.7, if any. Once the UE chooses a media security mechanism from the list received in the Security-Server header field from the server, it may initiate that mechanism on a media level when it initiates new media in an existing session;
5. if the Via header field contains a "keep" header field parameter with a value, continue to send keep-alives as described in RFC 6223, towards the P-CSCF;
6. if the 200 (OK) response contains the Authentication-Info header field including a nextnonce field, store the contained nonce as a nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used); and
7. if a Feature-Caps header field is received, a UE supporting the Feature-Caps header field shall consider the ICSI values received in the Feature-Caps header field of 200 (OK) response as supported for the established registration or registration flow (if the multiple registration mechanism is used) according to RFC 6809]; and
8. void.

When a 401 (Unauthorized) response to a REGISTER is received the UE shall behave as described in subclause 5.1.1.5.1. On receiving a 423 (Interval Too Brief) response to the REGISTER request, the UE shall:

• send another REGISTER request populating the registration expiration interval value with an expiration timer of at least the value received in the Min-Expires header field of the 423 (Interval Too Brief) response.

On receiving a 408 (Request Timeout) response or 500 (Server Internal Error) response or 504 (Server Time-Out) response or 403 (Forbidden) response for a reregistration, the UE shall perform the procedures for initial registration as described in subclause 5.1.1.2. On receiving a 305 (Use Proxy) response to the REGISTER request, unless otherwise specified in the access specific annexes (as described in Annex B, Annex L or Annex U), the UE shall:

1. ignore the contents of the Contact header field if it is included in the received message;
2. release all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2;
3. initiate either a new P-CSCF discovery procedure as described in subclause 9.2.1, or select a new P-CSCF, if the UE was pre-configured with more than one P-CSCF's IP addresses or domain names;
4. select a P-CSCF address, which is different from the previously used address, from the address list; and
5. perform the procedures for initial registration as described in subclause 5.1.1.2.

When the timer F expires at the UE:

1. the UE shall stop processing of all ongoing dialogs and transactions associated with that flow, if any (i.e. no further SIP signalling will be sent by the UE on behalf of these transactions or dialogs); and
2. after releasing all IP-CAN bearers used for the transport of media according to the procedures in subclause 9.2.2:
   1. the UE may select a different P-CSCF address from the list of P-CSCF addresses discovered during the procedures described in subclause 9.2.1 or from its pre-configured list of P-CSCF's IP addresses or domain names;
   2. if no response has been received when attempting to contact all P-CSCFs known by the UE, the UE may get a new set of P-CSCF-addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in Annex B, Annex L or Annex U);
   3. the UE may perform the procedures for initial registration as described in subclause 5.1.1.2; and
   4. the UE shall perform the procedures in RFC 5626 to form a new flow to replace the failed one if it supports multiple registrations. If failed registration attempts occur in the process of creating a new flow, the UE shall implement the flow recovery procedures defined in Section 4.5 of RFC 5626 for determination of the retry delay time before each new registration attempt. The UE shall use the values of the parameters max-time and base-time, of the algorithm defined in Section 4.5 of RFC 5626. If no values of the parameters max-time and base-time (if all failed) have been provided to the UE by the network, the default values defined in Section 4.5 of RFC 5626 shall be used.

On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field indicates time bigger than the value for timer F as specified in Table 7.7.1, the UE:

1. may mark the currently used P-CSCF address as unavailable for the time indicated by the Retry-After header field;
2. if there is a locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may initiate an initial registration as specified in subclause 5.1.1.2 using that P-CSCF; and
3. if there is no locally stored P-CSCF address as specified in subclause 5.1.9 which is different from the currently used P-CSCF address and which is not marked as unavailable, may get a new set of P-CSCF addresses as described in subclause 9.2.1 unless otherwise specified in the access specific annexes (as described in Annex B, Annex L or Annex U) and initiate an initial registration as specified in subclause 5.1.1.2.

On receiving a 503 response with a Retry-After header field to the REGISTER request and the Retry-After header field indicates time smaller than the value for timer F as specified in Table 7.7.1, after the time indicated by the Retry-After header field elapses:

1. if the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field or as retrieved from the Expires header field of the 2xx response to SUBSCRIBE request has not expired, the UE may attempt a reregistration to the same P-CSCF; or
2. if the expiration time as indicated in the "expires" header field parameter of the Subscription-State header field or as retrieved from the Expires header field of the 2xx response to SUBSCRIBE request has expired, the UE may attempt an initial registration as specified in subclause 5.1.1.2.

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field, with:
   • the "username" header field parameter set to the value of the private user identity;
   • the "realm" header field parameter directive, set to the value as received in the "realm" WWW-Authenticate header field parameter;
   • the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
   • the "nonce" header field parameter, set to last received nonce value; and
   • the "response" header field parameter, set to the last calculated response value;
2. additionally for the Contact header field, include the protected server port value in the hostport parameter;
3. additionally for the Via header field, for UDP, if the REGISTER request is protected by a security association, include the protected server port value in the sent-by field;
4. a Security-Client header field, set to specify the signalling plane security mechanism it supports, the IPsec layer algorithms for security and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see TS 33.203 and RFC 3329; and
5. a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On receiving the 200 (OK) response to the REGISTER request, the UE shall additionally:

1. set the security association lifetime associated with either this contact address or the registration flow and the associated contact address (if the multiple registration mechanism is used), and the associated set of security associations to the longest of either the previously existing security association lifetime, or the lifetime of the just completed registration plus 30 seconds.

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field as defined in RFC 7616 and RFC 8760, including:
   • the "username" header field parameter, set to the value of the private user identity;
   • the "realm" header field parameter, set to the domain name of the home network;
   • the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
   • the "nonce" header field parameter, set to the stored nonce value for authentication for the related registration or registration flow (if the multiple registration mechanism is used); and
   • the "response" header field parameter, set to the challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow ( if the multiple registration mechanism is used), along with "algorithm", "cnonce", "qop", and "nc" header field parameters as specified in RFC 7616 and RFC 8760;
2. the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent requests; and
3. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field set in accordance with subclause 5.1.1.4.3;
2. the Security-Client header field set to specify the signalling plane security mechanism the UE supports. The UE shall support the setup of a TLS session as defined in TS 33.203. The UE shall support the "tls" security mechanism, as specified in RFC 3329. The UE shall support TLS for integrity and confidentiality protection as defined in RFC 3261, and shall announce support for them according to the procedures defined in RFC 3329; and
3. a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, the UE shall additionally:

1. set the lifetime of the respective TLS session to the value configured.

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

1. optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.2.1, there are no additional requirements for the UE.

On sending a REGISTER request, as defined in subclause 5.1.1.4.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field as defined in RFC 7616 and RFC 8760 shall not be included, in order to indicate support GPRS-IMS-Bundled authentication.
2. security agreement header field values as required by RFC 3329 shall not contain signalling plane security mechanisms;
3. a From header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be registered;
4. a To header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be registered;
5. the Contact header field with the port value of an unprotected port where the UE expects to receive subsequent mid-dialog requests; and
6. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.4.1, there are no additional requirements for the UE.

Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations, deregistrations or registrations of additional public user identities. When the network requires authentication or re-authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request. On receiving a 401 (Unauthorized) response to the REGISTER request containing one or more WWW-Authenticate header fields the UE shall select the topmost header field that it supports (i.e. where the "algorithm" WWW-Authenticate header field parameter is "AKAv2-SHA-256" or "AKAv1-MD5"), the UE shall:

1. extract the RAND and AUTN parameters;
2. check the validity of a received authentication challenge, as described in TS 33.203 i.e. the locally calculated XMAC must match the MAC parameter derived from the AUTN part of the challenge; and the SQN parameter derived from the AUTN part of the challenge must be within the correct range; and
3. check the existence of the Security-Server header field as described in RFC 3329. If the Security-Server header field is not present or it does not contain the parameters required for the setup of the set of security associations (see Annex H of TS 33.203), the UE shall abandon the authentication procedure and send a new REGISTER request with a new Call-ID.

In the case that the 401 (Unauthorized) response to the REGISTER request is deemed to be valid the UE shall:

1. calculate the RES parameter and derive the keys CK and IK from RAND as described in TS 33.203;
2. set up a temporary set of security associations for this registration based on the static list and parameters the UE received in the 401 (Unauthorized) response and its capabilities sent in the Security-Client header field in the REGISTER request. The UE sets up the temporary set of security associations using the most preferred mechanism and algorithm returned by the P-CSCF and supported by the UE and using IK and CK (only if encryption enabled) as the shared key. The UE shall use the parameters received in the Security-Server header field to setup the temporary set of security associations. The UE shall set a temporary SIP level lifetime for the temporary set of security associations to the value of reg-await-auth timer;
3. store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports received in the Security-Server header field and labelled with the "mediasec" header field parameter specified in subclause 7.2A.7, if any
4. send another REGISTER request towards the protected server port indicated in the response using the temporary set of security associations to protect the message. The header fields are populated as defined for the initial REGISTER request that was challenged with the received 401 (Unauthorized) response, with the addition that the UE shall include an Authorization header field containing:
   • the "realm" header field parameter set to the value as received in the "realm" WWW-Authenticate header field parameter;
   • the "username" header field parameter, set to the value of the private user identity;
   • the "response" header field parameter that contains the RES parameter, as described in RFC 3310 when AKAv1 is used or as described in RFC 4169 when AKAv2 is used;
   • the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
   • the "algorithm" header field parameter, set to the value received in the 401 (Unauthorized) response; and
   • the "nonce" header field parameter, set to the value received in the 401 (Unauthorized) response.
   The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID of the security association protected REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge.

On receiving the 200 (OK) response for the security association protected REGISTER request registering a public user identity with the associated contact address, the UE shall:

• change the temporary set of security associations to a newly established set of security associations, i.e. set its SIP level lifetime to the longest of either the previously existing set of security associations SIP level lifetime, or the lifetime of the just completed registration plus 30 seconds; and
• if this is the only set of security associations available toward the P-CSCF, use the newly established set of security associations for further messages sent towards the P-CSCF. If there are additional sets of security associations (e.g. due to registration of multiple contact addresses), the UE can either use them or use the newly established set of security associations for further messages sent towards the P-CSCF as appropriate.

When the first request or response protected with the newly established set of security associations is received from the P-CSCF or when the lifetime of the old set of security associations expires, the UE shall delete the old set of security associations and related keys it may have with the P-CSCF after all SIP transactions that use the old set of security associations are completed. Whenever the 200 (OK) response is not received before the temporary SIP level lifetime of the temporary set of security associations expires or a 403 (Forbidden) response is received, the UE shall consider the registration to have failed. The UE shall delete the temporary set of security associations it was trying to establish, and use the old set of security associations. The UE should send an unprotected REGISTER request according to the procedure specified in subclause 5.1.1.2 if the UE considers the old set of security associations to be no longer active at the P-CSCF. In the case that the 401 (Unauthorized) response is deemed to be invalid then the UE shall behave as defined in subclause 5.1.1.5.3.

If, in a 401 (Unauthorized) response, either the MAC or SQN is incorrect the UE shall respond with a further REGISTER indicating to the S-CSCF that the challenge has been deemed invalid as follows:

• in the case where the UE deems the MAC parameter to be invalid the subsequent REGISTER request shall contain no "auts" Authorization header field parameter and an empty "response" Authorization header field parameter, i.e. no authentication challenge response;
• in the case where the UE deems the SQN to be out of range, the subsequent REGISTER request shall contain the "auts" Authorization header field parameter (see TS 33.102).

Whenever the UE detects any of the above cases, the UE shall:

• send the REGISTER request using an existing set of security associations, if available (see TS 33.203);
• populate a new Security-Client header field within the REGISTER request and associated contact address, set to specify the security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the parameters needed for the new security association setup. These parameters shall contain new values for spi_uc, spi_us and port_uc; and
• not create a temporary set of security associations.

On receiving a 420 (Bad Extension) in which the Unsupported header field contains the value "sec-agree" and if the UE supports GPRS-IMS-Bundled authentication, the UE shall initiate a new authentication attempt with the GPRS-IMS-Bundled authentication procedures as specified in subclause 5.1.1.2.6.

On receiving a 401 (Unauthorized) response to the REGISTER request containing one or more WWW-Authenticate header fields the UE shall select the topmost header field that it supports (i.e. where the "algorithm" WWW-Authenticate header field parameter is "SHA-256", "SHA-512-256" or "MD5"), and the UE shall:

1. extract the digest-challenge parameters as indicated in RFC 7616 and RFC 8760 from the WWW-Authenticate header field;
2. store the contained nonce value as the nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used);
3. calculate digest-response parameters as indicated in RFC 7616 and RFC 8760;
4. send another REGISTER request containing an Authorization header field. The header fields are populated as defined in subclause 5.1.1.2.3, with the addition that the UE shall include an Authorization header field containing a challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow (if the multiple registration mechanism is used) , "algorithm", "cnonce", "qop", and "nc" header field parameters as indicated in RFC 7616 and RFC 8760. The UE shall set the Call-ID of the REGISTER request which carries the authentication challenge response to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. If SIP digest without TLS is used, the UE shall not include RFC 3329 header fields with this REGISTER.

On receiving the 200 (OK) response for the REGISTER request, if the "algorithm" Authentication-Info header field parameter is "SHA-256", "SHA-512-256" or "MD5", the UE shall authenticate the S-CSCF using the "rspauth" Authentication-Info header field parameter as described in RFC 7616 and RFC 8760. If the nextnonce field is present in the Authentication-Info header field the UE shall store the contained nonce value as the nonce for authentication associated to the same registration or registration flow (if the multiple registration mechanism is used) and shall delete any other previously stored nonce value for authentication for this registration or registration flow (if the multiple registration mechanism is used).

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed.

On receiving a 401 (Unauthorized) response to the REGISTER request, the procedures in subclause 5.1.1.5.4 apply with the following differences:

• The UE shall check the existence of the Security-Server header field as described in RFC 3329. If the Security-Server header field is not present or the list of supported security mechanisms does not include "tls", the UE shall abandon the authentication procedure and send a new REGISTER request.

In the case that the 401 (Unauthorized) response to the REGISTER is deemed to be valid the UE shall:

• store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any; and
• send another REGISTER request using the TLS session to protect the message.

The header fields are populated as defined for the initial request, with the addition that the UE shall include an Authorization header field containing a challenge response, constructed using the stored nonce value for authentication for the same registration or registration flow (if the multiple registration mechanism is used), "algorithm", "cnonce", "qop", and "nc" header field parameters as indicated in RFC 7616 and RFC 8760. The UE shall also insert the Security-Client header field that is identical to the Security-Client header field that was included in the previous REGISTER request (i.e. the REGISTER request that was challenged with the received 401 (Unauthorized) response). The UE shall also insert the Security-Verify header field into the request, by mirroring in it the content of the Security-Server header field received in the 401 (Unauthorized) response. The UE shall set the Call-ID to the same value as the Call-ID of the 401 (Unauthorized) response which carried the challenge. When SIP digest with TLS is used, and for the case where the 401 (Unauthorized) response to the REGISTER request is deemed to be valid, the UE shall establish the TLS session as described in TS 33.203. The UE shall use this TLS session to send all further messages towards the P-CSCF towards the protected server port.

On receiving a 403 (Forbidden) response, the UE shall consider the registration to have failed. If performing SIP digest with TLS, the UE should send an initial REGISTER according to the procedure specified in subclause 5.1.1.2 if the UE considers the TLS session to be no longer active at the P-CSCF.

NASS-IMS bundled authentication is only applicable to UEs that contain neither USIM nor ISIM. Authentication is achieved via the registration and reregistration procedures as defined in subclause 5.1.1.2 and subclause 5.1.1.4. NASS-bundled authentication is granted by the network upon receipt by the UE of a 200 (OK) response to the initial REGISTER request. There is no separate authentication procedure.

There is no separate authentication procedure, and therefore no abnormal procedures.

Authentication is achieved via the registration and reregistration procedures as defined in subclause 5.1.1.2 and subclause 5.1.1.4. GPRS-IMS-Bundled authentication is granted by the network upon receipt by the UE of a 200 (OK) response to the initial REGISTER request.

There is no separate authentication procedure and therefore no abnormal procedures.

A UE shall only respond to two consecutive invalid challenges. The UE may attempt to register with the network again after an implementation specific time.

For any public user identity that the UE has previously registered, the UE can deregister via a single registration procedure:

• all contact addresses bound to the indicated public user identity;
• some contact addresses bound to the indicated public user identity;
• a particular contact address bound to the indicated public user identity; or
• when the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field) one or more flows bound to the indicated public user identity.

The UE can deregister a public user identity that it has previously registered with its contact address at any time. The UE shall protect the REGISTER request using a security association or TLS session that is associated with contact address, see TS 33.203, established as a result of an earlier registration, if one is available. The UE shall extract or derive a public user identity, the private user identity, and the domain name to be used in the Request-URI in the registration, according to the procedures described in subclause 5.1.1.1A or subclause 5.1.1.1B. Prior to sending a REGISTER request for deregistration, the UE shall release all dialogs that were using the contact addresses or the flow that is going to be deregistered and related to the public user identity that is going to be deregistered or to one of the implicitly registered public user identities. However:

• if the dialog that was established by the UE subscribing to the reg event package used the public user identity that is going to be deregistered; and
• this dialog is the only remaining dialog used for subscription to reg event package of the user, i.e. there are no other contact addresses registered with associated subscription to the reg event package of the user;

then the UE shall not release this dialog. On sending a REGISTER request that will remove the binding between the public user identity and one of its contact addresses or one of its flows, the UE shall populate the header fields as follows:

1. a From header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be deregistered;
2. a To header field set to the SIP URI that contains:
   1. if the UE supports RFC 6140 and performs the functions of an external attached network, the main URI of the UE; else
   2. the public user identity to be deregistered;
3. a Contact header field set to the SIP URI(s) that contain(s) in the hostport parameter the IP address of the UE or FQDN, and:
   1. if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities), and the contact address indicated in the Contact header field; and
      • if the UE supports GRUU, or multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), or has an IMEI available, or has an MEID available, the Contact header field also contains the "+sip.instance" header field parameter. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks;
      • if the UE supports multiple registrations (i.e. the "outbound" option tag is included in the Supported header field), the Contact header field does not contain the "reg-id" header field parameter;
      • if the UE does not supports GRUU and does not support multiple registrations (i.e. the "outbound" option tag is not included in the Supported header field), and does not have an IMEI available, and does not have an MEID available, the Contact header field does not contain either the "+sip.instance" header field parameter or the "reg-id" header field parameter;
   2. if the UE is removing the binding between the public user identity indicated in the To header field, (together with the associated implicitly registered public user identities) and one of its flows, the Contact header field contains the "+sip.instance" header field parameter and the "reg-id" header field parameter that identifies the flow; and
4. if the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Contact URI without a user portion and containing the "bnc" URI parameter;
5. a Via header field set to include the IP address or FQDN of the UE in the sent-by field;
6. a registration expiration interval value set to the value of zero, appropriate to the deregistration requirements of the user;
7. a Request-URI set to the SIP URI of the domain name of the home network used to address the REGISTER request;
8. if available to the UE (as defined in the access technology specific annexes for each access technology), a P-Access-Network-Info header field set as specified for the access network technology (see subclause 7.2A.4);
9. a Security-Client header field to announce the media plane security mechanisms the UE supports, if any;
10. if the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Require header field containing the option-tag "gin"; and
11. if the UE supports RFC 6140 and performs the functions of an external attached network, for the registration of bulk number contacts the UE shall include a Proxy-Require header field containing the option-tag "gin".

For a public user identity that the UE has registered with multiple contact addresses or multiple flows (e.g. via different P-CSCFs), the UE shall also be able to deregister multiple contact addresses or multiple flows, bound to its public user identity, via single deregistration proceduere as specified in RFC 3261. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a list of Contact headers. Each Contact header field is populated as specifed above in bullets a) through i). The UE can deregister all contact addresses bound to its public user identity and associated with its private user identity. The UE shall send a single REGISTER request, using one of its contact addresses and the associated set of security associations or TLS session, containing a public user identity that is being deregistered in the To header field, and a single Contact header field with value of "*" and the Expires header field with a value of "0". The UE shall not include the "instance-id" feature tag and the "reg-id" header field parameter in the Contact header field in the REGISTER request. When a 401 (Unauthorized) response to a REGISTER request is received the UE shall behave as described in subclause 5.1.1.5.1. On receiving the 200 (OK) response to the REGISTER request, the UE shall:

• remove all registration details relating to this public user identity and the associated contact address.
• store the announcement of the media plane security mechanisms the P-CSCF (IMS-ALG) supports labelled with the "mediasec" header field parameter specified in subclause 7.2A.7 and received in the Security-Server header field, if any.

If there are no more public user identities registered with this contact address, the UE shall delete any stored media plane security mechanisms and related keys and any security associations or TLS sessions and related keys it may have towards the IM CN subsystem. If all public user identities are deregistered and all security association or TLS session is removed, then the UE shall consider subscription to the reg event package cancelled (i.e. as if the UE had sent a SUBSCRIBE request with an Expires header field containing a value of zero).

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field, with:
   • the "username" header field parameter, set to the value of the private user identity;
   • the "realm" header field parameter, set to the value as received in the "realm" WWW-Authenticate header field parameter;
   • the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
   • the "nonce" header field parameter, set to last received nonce value; and
   • the response directive, set to the last calculated response value;
2. additionally for each Contact header field and associated contact address, include the associated protected server port value in the hostport parameter;
3. additionally for the Via header field, include the protected server port value bound to the security association in the sent-by field;
4. a Security-Client header field, set to specify the signalling plane security mechanisms it supports, the IPsec layer algorithms for integrity and confidentiality protection it supports and the new parameter values needed for the setup of two new pairs of security associations. For further details see TS 33.203 and RFC 3329; and
5. a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field as defined in RFC 7616 and RFC 8760, including:
   • the "username" header field parameter, set to the value of the private user identity;
   • the "realm" header field parameter, set to the domain name of the home network;
   • the "uri" header field parameter, set to the SIP URI of the domain name of the home network;
   • the "nonce" header field parameter, set to an empty value; and
   • the "response" header field parameter, set to an empty value;
2. for each Contact header field and associated contact address include the associated unprotected port value (where the UE was expecting to receive mid-dialog requests); and
3. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field set in accordance with subclause 5.1.1.6.3; and
2. a Security-Client header field, set to specify the signalling plane security mechanism it supports. For further details see TS 33.203 and RFC 3329; and
3. a Security-Verify header field that contains the content of the Security-Server header field received in the 401 (Unauthorized) response of the last successful authentication.

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

1. optionally, an Authorization header field, with the "username" header field parameter, set to the value of the private user identity;

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.6.1, there are no additional requirements for the UE.

On sending a REGISTER request, as defined in subclause 5.1.1.6.1, the UE shall additionally populate the header fields as follows:

1. an Authorization header field as defined in RFC 7616 and RFC 8760 shall not be included, in order to indicate support GPRS-IMS-Bundled authentication.
2. the Security-Verify header field and the Security-Client header field values as defined by RFC 3329 shall not contain signalling plane security mechanisms;
3. a From header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be deregistered;
4. a To header field set to a temporary public user identity derived from the IMSI, as defined in TS 23.003, as the public user identity to be deregistered;
5. for each Contact header field and associated contact address include the associated unprotected port value (where the UE was expecting to receive mid-dialog requests); and
6. the Via header field with the port value of an unprotected port where the UE expects to receive responses to the request.

On receiving the 200 (OK) response to the REGISTER request defined in subclause 5.1.1.6.1, there are no additional requirements for the UE.