O.4 Management of TLS sessions

33.2033G Security3GPPAccess security for IP-based servicesTS

O.4.1 Management of TLS sessions at the UE

The UE shall be involved in only one registration procedure at a time, i.e., the UE shall remove any data relating to any previous incomplete registrations, including any TLS connection and session successfully created in a previous incomplete registration procedure.

When the UE receives a HELLO request from the P-CSCF it should initiate a renegotiation. The UE shall send all TLS session renegotiation messages inside the existing TLS connection.

When the TLS connection is lost the UE shall initiate a registration procedure according to Annex N.

O.4.2 Management of TLS sessions at the P-CSCF

The lifetime of the TLS session negotiated between the UE and the P-CSCF is subject to local policies.

The P-CSCF may trigger a TLS session renegotiation at any time by sending a HELLO request message to the UE. The P-CSCF shall send this message and all TLS session renegotiation messages inside the existing TLS connection. According to its local policy, the PCSCF may abort the communication if the UE does not initiate a TLS session renegotiation.

When the TLS session renegotiation is successfully completed, the P-CSCF shall replace the old Session ID with the new TLS Session ID associated with the UE’s IP address and port of the TLS connection, the IMPI and all the successfully registered IMPUs related to that IMPI, cf. clause O.2.2.

The P-CSCF shall accept TLS handshake messages outside TLS connections associated with an existing registration only during a registration procedure according to Annex N.

O.4.3 Authenticated re-registration

If the UE has an already active TLS session, then it shall use this to protect the REGISTER message for re-registration.

When the P-CSCF receives a REGISTER message protected by a TLS session whose TLS Session ID is associated with an IMPI from a previously successful registration (cf. O.2.2), then the P-CSCF shall proceed as follows:

– If the IMPI is present in the REGISTER message the P-CSCF shall verify that the IMPI in the REGISTER matches the IMPI associated with the TLS Session ID. If the IMPIs match, then the P-CSCF shall forward this REGISTER message together with a TLS integrity protection indicator indicating the logical value "authentication complete".

– If the IMPI is not present in the REGISTER message the P-CSCF shall not include any TLS integrity protection indicator.

When the S-CSCF receives a REGISTER message with a TLS integrity protection indicator indicating the logical value "authentication complete" it may authenticate the user by means of SIP Digest, according to the local security policy of the S-CSCF. When the S-CSCF receives a REGISTER message with no TLS integrity protection indicator the S-CSCF shall challenge the user by sending a SIP 401 Auth_Challenge.

If the UE considers the TLS session no longer active at the P‑CSCF, e.g., after receiving no response to several protected messages, then the UE should send an unprotected REGISTER message. In this case, the S‑CSCF shall determine the applicable authentication scheme according to Annex P.