Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.4  Procedures at the S-CSCFWord‑p. 228

5.4.0  General |R8|

Where the S-CSCF provides emergency call support, the procedures of subclause 5.4.8 shall be applied first.
Upon
  1. a third-party registration due to initial registration on behalf of a served public user identity; or
  2. a trigger to an AS for an unregistered public user identity and there is no IP address of that AS associated with that public user identity stored;
the S-CSCF shall store the IP address of the AS and associate the IP address with the public user identity and the AS SIP URI along with all URI parameters.
When sending a failure response to any received request, depending on operator policy, the S-CSCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "s-cscf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17. A S-CSCF when sending a failure response will add in the URN the "side" header field parameter set to:
  • "orig" for a UE-originating case; and
  • "term" for a UE-terminating case.
Up

5.4.1  Registration and authentication

5.4.1.1  Introduction

The S-CSCF shall determine which authentication mechanism applies based on the contents of the REGISTER request and the authentication mechanism assigned in the HSS:
1)
if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "no", the S-CSCF shall perform the initial registration procedures with IMS-AKA authentication described in subclauses 5.4.1.2.1 and 5.4.1.2.1A;
2)
if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "yes", the S-CSCF shall perform the protected registration procedures with IMS-AKA as a security mechanism as described in subclause 5.4.1.2.2;
2A)
if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "tls-connected" and with the "algorithm" header field parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association, the S-CSCF shall perform:
  1. if the REGISTER request does not contain an authentication challenge response, the initial registration procedures for IMS-AKA authentication described in subclauses 5.4.1.2.1 and 5.4.1.2.1A; or
  2. if the REGISTER request contains an authentication challenge response, the protected registration procedures with IMS-AKA as a security mechanism as described in subclause 5.4.1.2.2;
3)
if the REGISTER request does not contain an Authorization header field, then the S-CSCF shall identify the user by the public user identity as received in the To header field of the REGISTER request. The S-CSCF shall derive the private user identity from the public user identity being registered. The S-CSCF shall derive the private user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters or by alternative mechanisms to derive the private user identity if operator policy requires to do so. These alternative mechanisms are not defined in this version of the specification;
4)
if the REGISTER request does not contain an Authorization header field and the access-type field in the P-Access-Network-Info header field indicated xDSL, Ethernet, or Fiber access, and containing the "network provided" header field parameter and the S-CSCF supports NASS-IMS-bundled authentication but does not support SIP digest, then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D;
5)
if the REGISTER request does not contain an Authorization header field and the access-type field in the P-Access-Network-Info header field indicates it is received from an IP-CAN different from 3GPP and containing the "network provided" header field parameter and the S-CSCF supports SIP digest but does not support NASS-IMS-bundled authentication, then the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B;
6)
if the REGISTER request does not contain an Authorization header field and there is no P-Access-Network-Info header field containing the "network provided" field or there is a P-Access-Network-Info header field indicating a 3GPP access network containing the "network provided", and the S-CSCF supports GPRS-IMS-Bundled authentication, the S-CSCF shall perform the initial registration procedures with GPRS-IMS-Bundled authentication described in subclause 5.4.1.2.1E;
7)
if the REGISTER request does not contain an Authorization header field, and the P-Access-Network-Info header field indicates it is received from an access network other than 3GPP, xDSL, Ethernet or Fiber and containing the "network provided" header field parameter, and the S-CSCF supports SIP digest and NASS-IMS bundled authentication, the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B:
8)
if the REGISTER request does not contain an Authorization header field, and the P-Access-Network-Info header field indicates it is received from a xDSL, Ethernet or Fiber access network, and containing the "network provided" header field parameter, and the S-CSCF supports SIP digest and NASS-IMS bundled authentication, the S-CSCF sends an authentication request for the user to the HSS indicating that the authentication scheme is unknown as described in TS 29.228:
  • if the HSS responds with an authentication scheme of SIP digest, then the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B; or
  • if the HSS responds with an authentication scheme of NASS-IMS bundled authentication and the request was received from a P-CSCF in the home network and the P-CSCF is "TISPAN-enabled", then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D;
9)
if the REGISTER request contains an Authorization header field without an "integrity-protected" header field parameter, the S-CSCF shall send an authentication request for the user to the HSS indicating that the authentication scheme is unknown as described in TS 29.228:
  • if the HSS responds with an authentication scheme of NASS-IMS bundled authentication and the request was received from a P-CSCF is in the home network and the P-CSCF is "TISPAN-enabled", then the S-CSCF shall perform the initial registration procedures with NASS-IMS bundled authentication as a security mechanism as described in subclause 5.4.1.2.1D; or
  • if the HSS responds with an authentication scheme of SIP digest, then the S-CSCF shall perform the initial registration procedures with SIP digest as a security mechanism as described in subclauses 5.4.1.2.1 and 5.4.1.2.1B;
10)
if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "tls-pending", "tls-yes", "ip-assoc-pending" or "ip-assoc-yes", the S-CSCF shall perform the protected registration procedures for SIP digest described in subclause 5.4.1.2.2A;
11)
if the REGISTER request contains an Authorization header field with the "integrity-protected" header field parameter set to "auth-done", the S-CSCF shall perform the protected registration procedures described in subclause 5.4.1.2.2E; and
12)
if the REGISTER request contains a JSON Web Token with the "3gpp-waf" JSON Web Token claim or with the "3gpp-wwsf" JSON Web Token claim, as defined in RFC 7519, and if the S-CSCF supports WebRTC, and if the S-CSCF has received authorization information about WAF or WWSF entities from the HSS, or per configuration, then the S-CSCF shall check whether the WAF or WWSF is not barred, as specified in TS 33.203 annex X. If the WAF or the WWSF is barred, the S-CSCF shall send a 403 (Forbidden) response to the REGISTER request.
The S-CSCF shall act as the SIP registrar for all UEs belonging to the IM CN subsystem and with public user identities.
Subclause 5.4.1.2 through subclause 5.4.1.7 define S-CSCF procedures for SIP registration that do not relate to emergency. All registration requests are first screened according to the procedures of subclause 5.4.8.2 to see if they do relate to an emergency registration.
For all SIP registrations identified:
  • as relating to an emergency; or
  • if priority is supported, as containing an authorised Resource-Priority header field;
the S-CSCF shall give priority over other registrations. This allows special treatment of such registrations.
The S-CSCF shall support the use of the Path and Service-Route header field. The S-CSCF shall also support the Require and Supported header fields. The Path header field is only applicable to the REGISTER request and its 200 (OK) response. The Service-Route header field is only applicable to the 200 (OK) response of REGISTER. The S-CSCF shall not act as a redirect server for REGISTER requests.
The network operator defines minimum and maximum times for each registration. These values are provided within the S-CSCF.
The procedures for notification concerning automatically registered public user identities of a user are described in subclause 5.4.2.1.2.
If the S-CSCF supports HSS based P-CSCF restoration procedures, and receives a REGISTER request from a P-CSCF that the S-CSCF considers is in a non-working state, the S-CSCF shall consider this P-CSCF as being in a working state.
If the S-CSCF supports PCRF based P-CSCF restoration procedures, and receives a REGISTER request from a P-CSCF that the S-CSCF considers is in a non-working state, the S-CSCF shall consider this P-CSCF as being in a working state.
In case a device performing address and/or port number conversions is provided by a NA(P)T or NA(P)T-PT, the S-CSCF may need to modify the SIP signalling according to the procedures described in annex K if both a "reg-id" and "+sip.instance" header field parameter are present in the received Contact header field as described in RFC 5626.
Up

5.4.1.2  Initial registration and user-initiated reregistrationWord‑p. 230
5.4.1.2.1  Unprotected REGISTER
Any REGISTER request received unprotected by the S-CSCF without an Authorization header field, or with an Authorization header field having the "integrity-protected" header field parameter in the Authorization header field set to "no", or without an "integrity-protected" header field parameter is considered to be an initial registration. If such an initial registration contains a private user identity specifically reserved for IM CN subsystem registrations from an MSC Server enhanced for ICS as defined in TS 23.003, the S-CSCF shall respond with a 403 (Forbidden) response. The S CSCF shall consider this registration attempt as failed..
Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity for which the maximum number of allowed simultaneously registration flows for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause.
Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a user identity linked to a private user identity and instance ID/reg-id if available, that has previously registered one or more public user identities, the S-CSCF shall:
  1. perform the procedure below in this subclause for receipt of a REGISTER request for a public user identity which is not already registered, for the received public user identity;
  2. if the multiple registrations is not used and if the authentication that in step 1) has been successful, and there are public user identities (including the public user identity being registered, if previously registered) that belong to this user that have been previously registered with the same private user identity, and with an old contact address different from the one received in the REGISTER request, and the previous registrations have not expired, perform the network initiated deregistration procedure (as described in subclause 5.4.1.5) for the previously registered public user identities belonging to this user including the public user identity being registered, if previously registered; and
  3. if the multiple registrations is used (i.e., the "reg-id" header field parameter is included in the REGISTER request), and if the authentication that concludes the initial registration has been successful, and if the public user identity being registered has been previously registered with the same private user identity and the same "+sip.instance" and "reg-id" header field parameter values, and the previous registration has not expired:
    1. identify the registration flow being replaced;
    2. terminate any dialog, as specified in subclause 5.4.5.1.2, with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, associated with the registration flow being replaced; and
    3. send a NOTIFY request to the subscribers to the registration event package for the public user identity indicated in the REGISTER request, as described in subclause 5.4.2.1.2.
When S-CSCF receives a REGISTER request with the "integrity-protected" header field parameter in the Authorization header field set to "no" and a non-empty "response" Authorization header field parameter, the S-CSCF shall ignore the value of the "response" header field parameter.
Upon receipt of a REGISTER request that is part of an initial registration as outlined above, for a public user identity which is not already registered linked to the same private user identity and the "+sip.instance" and "reg-id" header field parameters, if available, the S-CSCF shall:
  1. identify the user by the public user identity as received in the To header field and if the REGISTER request includes an Authorization header field, identify the private user identity as received in the "username" Authorization header field parameter of the REGISTER request;
  2. check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;
  3. select an authentication vector for the user. If no authentication vector for this user is available, after the S-CSCF has performed the Authentication procedure with the HSS, as described in TS 29.228, the S-CSCF shall select an authentication vector as described in TS 33.203.
    Prior to performing Authentication procedure with the HSS, the S-CSCF decides which HSS to query, possibly as a result of a query to the Subscription Locator Functional (SLF) entity as specified in TS 29.228 or use the value as received in the P-User-Database header field in the REGISTER request as defined in RFC 4457;
  4. store the "icid-value" header field parameter received in the P-Charging-Vector header field;
  5. challenge the user by generating a 401 (Unauthorized) response for the received REGISTER request appropriate to the security mechanism in use;
  6. send the so generated 401 (Unauthorized) response towards the UE, and if the URI in the first Path header field has an "ob" SIP URI parameter, include a Require header field with the option-tag "outbound" as described in RFC 5626; and
  7. start timer reg-await-auth which guards the receipt of the next REGISTER request.
If the received REGISTER request indicates that the challenge sent previously by the S-CSCF to the UE was deemed to be invalid by the UE, the S-CSCF shall stop the timer reg-await-auth and proceed as described in the subclause 5.4.1.2.3.
Up
5.4.1.2.1A  Challenge with IMS AKA as security mechanism |R8|Word‑p. 232
On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:
  1. a WWW-Authenticate header field which transports:
    1. a globally unique name of the S-CSCF in the "realm" header field parameter;
    2. the RAND and AUTN parameters and optional server specific data for the UE in the "nonce" header field parameter;
    3. if the REGISTER request does not contain an Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256":
      • the security mechanism, which is "AKAv1-MD5", in the "algorithm" header field parameter;
      • the IK (Integrity Key) parameter for the P-CSCF in the "ik" header field parameter (see subclause 7.2A.1); and
      • the CK (Cipher Key) parameter for the P-CSCF in the "ck" header field parameter (see subclause 7.2A.1); and
    4. if the REGISTER request does contain an Authorization header field with the "algorithm" header field parameter set to "AKAv2-SHA-256", and if the S-CSCF supports the IMS AKA using HTTP Digest AKAv2 without IPSec security association:
      • the security mechanism, which is "AKAv2-SHA-256" in the "algorithm" header field parameter.
The S-CSCF shall store the RAND parameter used in the 401 (Unathorized) response for future use in case of a resynchronisation. If a stored RAND already exists in the S-CSCF, the S-CSCF shall overwrite the stored RAND with the RAND used in the most recent 401 (Unauthorized) response.
Up
5.4.1.2.1B  Challenge with SIP digest as security mechanism |R8|Word‑p. 233
On sending a 401 (Unauthorized) response to an unprotected REGISTER request, the S-CSCF shall populate the header fields as follows:
  1. a WWW-Authenticate header field as defined in RFC 2617, which transports:
    • a protection domain in the "realm" header field parameter;
    • a "nonce" header field parameter (generated by the S-CSCF);
    • an "algorithm" header field parameter; if the algorithm value is not provided in the authentication vector, it shall have the value "MD5"; and
    • a "qop" header field parameter; if the qop value is not provided in the authentication vector, it shall contain the value "auth".
Up
5.4.1.2.1C  Challenge with SIP digest with TLS as security mechanism |R8|
The procedures for subclause 5.4.1.2.1B apply.
5.4.1.2.1D  Initial registration and user-initiated reregistration for NASS-IMS bundled authentication |R8|
Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a user identity linked to a private user identity that has a registered public user identity but with a new contact address, the S-CSCF shall:
  1. perform the procedure for receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without the Authorization header field, for the received public user identity; and
  2. if the Contact header field of the REGISTER request does not contain a "reg-id" header field parameter (i.e., the multiple registrations mechanism is not used), and the authentication has been successful, and there are public user identities (including the public user identity being registered, if previously registered) belonging to this user that have been previously registered with the same private user identity and with an old contact address different from the one received in the REGISTER request and if the previous registration have not expired:
    1. terminate all dialogs, if any, associated with the previously registered public user identities (including the public user identity being registered, if previously registered), with a status code 480 (Temporarily Unavailable) in the Reason header field of the BYE request, as specified in subclause 5.4.5.1.2;
    2. send a NOTIFY request, to the subscribers to the registration event package of the previously registered public user identities, that indicates that all previously registered public user identities (excluding the public user identity being registered) belonging to this user identified with its private user identity, have been deregistered, as described in subclause 5.4.2.1.2. For the public user identity being registered, the NOTIFY request contains the new contact information; and
    3. delete all information associated with the previously registered public user identities.
Upon receipt of a REGISTER request that is determined to be NASS-IMS bundled authentication, for a public user identity for which the maximum number of allowed simultaneously registration flows is for the used UE (i.e. linked to the same private user identity and instance ID) is reached, if the REGISTER is adding a new registration flow, then the S-CSCF shall reject the REGISTER by generating a 403 (Forbidden) response. If not, the S-CSCF shall continue with the rest of the procedures of this subclause;
Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, which is not for an already registered public user identity linked to the same private user identity, the S-CSCF shall:
  1. identify the user by the public user identity as received in the To header field of the REGISTER request and if the Authorization header field is present, the private user identity as received in the Authorization header field of the REGISTER request. If the Authorization header field is not present, the S-CSCF shall derive the private user identity from the public user identity being registered by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters;
  2. check whether one or more Line-Identifiers previously received over the Cx interface, and stored as a result of a Authentication procedure with the HSS, are available for the user. If not, the S-CSCF performs the Authentication procedure with the HSS, as described in TS 29.228, in order to obtain these Line-Identifiers;
  3. in the particular case where the S-CSCF received via the Cx interface one or more Line-Identifiers, compare each of Line-Identifiers with the "dsl-location", "eth-location" or "fiber-location" parameter of the P-Access-Network-Info header field (if present and if it includes the "network-provided" parameter):
    • if one of these match, the user is considered authenticated, behave as described in step 5) to 11) of subclause 5.4.1.2.2;
    • otherwise i.e. if these do not match, return a 403 (Forbidden) response to the REGISTER request; and
  4. if no Line-Identifier is received over the Cx interface, send a 500 (Server Internal Error) response to the REGISTER request.
Upon receipt of a REGISTER request without the "integrity-protected" header field parameter in the Authorization header field or without an Authorization header field, for an already registered public user identity linked to the same private user identity, and for existing contact information, the S-CSCF shall behave as described in subclause 5.4.1.2.2F.
Up
5.4.1.2.1E  Initial registration and user-initiated reregistration for GPRS-IMS-Bundled authentication |R8|Word‑p. 234
Upon receipt of a REGISTER request without an Authorization header field, the S-CSCF shall:
1)
identify the user by the public user identity as received in the To header field of the REGISTER request. The S-CSCF shall derive the private user identity from the public user identity being registered by removing URI scheme and the following parts of the URI if present: port number, URI parameters, and To header field parameters;
1A)
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 the rest of the steps;
2)
check if the P-Visited-Network-ID header field is included in the REGISTER request, and if it is included identify the visited network by the value of this header field;
3)
check whether an IP address is stored for this UE. If no IP address (or prefix) is stored for the UE, query the HSS as described in TS 29.228 with the derived private user identity and the public user identity as input and store the received IP address (or prefix) of the UE; if the S-CSCF receives a prefix from the HSS, it will only check against prefixes otherwise it will check against the full IP address;
4)
check whether a "received" header field parameter exists in the Via header field provided by the UE. If a "received" header field parameter exists, the S-CSCF shall compare the IP address recorded in the "received" header field parameter against the UE's IP address stored during registration. In case of IPv6 stateless autoconfiguration, the S-CSCF shall compare the prefix of the IP address recorded in the "received" header field parameter against the UE's IP address prefix stored during registration. If no "received" header field parameter exists in the Via header field provided by the UE, then the S-CSCF shall compare IP address recorded in the "sent-by" parameter against the stored UE IP address. In case of IPv6 stateless autoconfiguration, S-CSCF shall compare the prefix of the IP address recorded in the "sent-by" parameter against the UE's IP address prefix stored during registration. In any case, if the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE do not match, the S CSCF shall query the HSS as described in TS 29.228 with the derived private user identity and the public user identity as input and store the received IP address (or prefix) of the UE. If the stored IP address (or prefix) and the (prefix of the) IP address recorded in the Via header field provided by the UE still do not match the S-CSCF shall reject the registration with a 403 (Forbidden) response and skip the following steps;
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:
  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 unregisterd part is retained for possible use later - in the case the S-CSCF is retained if the user becomes unregistered);
  3. if S-CSCF restoration procedures are supported, the restoration information if received as specified in TS 29.228; and
  4. 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 as follows:
  1. 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; and
  2. 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;
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 to 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 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;
9A)
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
10)
create and send a 200 (OK) response for the REGISTER request as specified in subclause 5.4.1.2.2F.
When a user de-registers, or is de-registered by the HSS, the S-CSCF shall delete the IP address stored for the UE.
Up


Up   Top   ToC