O.2 TLS Session set-up procedure

33.2033G Security3GPPAccess security for IP-based servicesTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

O.2.1 TLS Profile for TLS based access security

When the UE and the P-CSCF implement and use TLS as specified in the present Annex O, TLS shall be implemented and used according to the TLS profile specified in TS 33.310 [24], Annex E. For all TLS versions the provisions on ciphersuites given in TS 33.310 [24], Annex E, shall apply.

NOTE 0: Void.

– Authentication of the P-CSCF

– The P-CSCF shall be authenticated by the UE by presenting a valid server certificate. The P-CSCF certificate profile shall be based on TLS certificates as presented in clause O.5.1.

– Authentication of the UE

– The P-CSCF shall not request a certificate in a Server Hello Message from the UE. The HN shall authenticate the UE as specified in Annex N of this specification.

– Verification of the TLS session endpoints

– In order for the UE to be able to trust the TLS session endpoint, the P-CSCF certificate shall be used during the authentication procedure.

– In order for the P-CSCF to be able to trust that the UE, which was authenticated according to Annex N, is the TLS session endpoint, the P-CSCF shall use the mechanism for associating the TLS Session ID with registration parameters IP address, port, IMPI, IMPU(s), specified in clause O.2.2, and shall have assurance that man-in-the-middle attacks can be mitigated, e.g. by following the rules in the NOTE in clause O.1.1.

– TLS session parameters

The TLS Handshake Protocol negotiates a session, which is identified by a Session ID.

– The lifetime of a Session ID is subject to local policies of the UE and the P-CSCF. A recommended lifetime is one hour (or at least more than the re-REGISTRATION time out). The procedure for TLS session re-negotiation in IMS is specified in clauses O.4.1 and O.4.2.

– Ports

– The P-CSCF shall be prepared to accept TLS session requests on port 5061 or on a port published by the operator.

– Forwarding requests

– The procedures for forwarding requests by the edge proxy in RFC 5626 [32] shall apply to the P-CSCF when managing TLS connections.

NOTE 1: The use of RFC 5626 [32] in conjunction with TLS is needed so that terminating requests can re-use an existing TLS connection.

O.2.2 TLS session set-up during registration

The TLS session set-up procedure is necessary in order to decide what security services to apply and when the security services start. In the IMS, authentication of users is performed during registration. Subsequent signalling communications in this session will be integrity protected based on the TLS session that was established during the authentication process.

The set-up of the TLS session between the UE and the P-CSCF is based on the TLS profile specified in clause O.2.1. The sip-sec-agree negotiation according to RFC 3329 [21] is performed during the registration procedure to negotiate the choice of the security mechanism. Annex H of this specification describes the parameters of RFC 3329 [21] for the set-up of TLS sessions.

The following describes how TLS session set-up is integrated with the initial registration procedure described in Annex N.1:

Up to and including message SM6 received by the UE, the procedures for the cases with and without TLS are identical, except for the following:

– In SM1 the UE includes sip-sec-agree negotiation headers according to RFC 3329 [21], which must include one header with value "tls" (cf. annex H), if TLS is to be used.

– In SM 6 the P-CSCF includes sip-sec-agree negotiation headers, which must include one header with value "tls" and the highest q-value of all security mechanisms common to UE and P-CSCF (cf. annex H), if TLS is to be used.

After receiving SM6, when TLS was selected by the P-CSCF the procedure continues as follows:

– the UE performs a TLS handshake with the P-CSCF; the UE shall not re-use an existing TLS connection for initial registrations;

– after successful establishment of a TLS connection, the UE sends SM7 over this TLS connection, including sip-sec-agree negotiation headers;

– the P-CSCF then sends SM8, together with a TLS integrity protection indicator indicating the logical value "authentication pending".

– the S-CSCF receives this message as SM9 and treats it according to Annex N. If the authentication of the UE is successful the S-CSCF shall associate the registration with the local state "tls-protected".

– when the P-CSCF receives message SM11 (200 OK) it shall associate the UE’s IP address and port of the TLS connection with the TLS Session ID, the IMPI and all the successfully registered IMPUs related to that IMPI. From this point on, the P-CSCF shall not accept any SIP signalling messages outside the TLS connection other than REGISTER messages, messages relating to emergency services in accordance with TS 24.229 [8] and TS 23.167 [31], and error messages.

– after the UE has received SM12 it shall not accept any SIP signalling messages outside the TLS connection other than responses to REGISTER messages, messages relating to emergency services in accordance with TS 24.229 [8] and TS 23.167 [31], and error messages.

An S-CSCF shall accept a REGISTER message with a TLS integrity protection indicator indicating "authentication pending" only if it contains a verifiable Digest value computed over a valid challenge according to Annex N.

NOTE: The S-CSCF may have a local security policy to treat messages other than initial REGISTER messages, messages relating to emergency services, and error messages, differently depending on whether the registration is associated with the state "tls-protected".

O.2.3 TLS session set-up prior to Initial registration

The set-up of the TLS session between the UE and the P-CSCF is based on the TLS profile specified in clause O.2.1. Annex H of this specification describes the parameters of RFC 3329 [21] for the set-up of TLS sessions during Initial registration.

NOTE 1: The sip-sec-agree negotiation according to RFC 3329 [21] is not used for this TLS variant.

The following describes how TLS session set-up is performed prior to the initial registration procedure described in Annex N.2.1.1 (Figure N.1):

– Prior to SM1 the UE performs a TLS handshake with the P-CSCF; the UE shall not re-use an existing TLS connection for initial registrations.

– After successful establishment of a TLS connection, the UE sends SM1 over this TLS connection. All subsequent messages will be sent over this TLS connection.

NOTE 2: Sec-agree is not used as TLS is selected from start.

– When P-CSCF receives SM7, the P-CSCF then sends SM8, together with a TLS integrity protection indicator indicating the logical value "authentication pending".

– The S-CSCF receives this message as SM9 and treats it according to Annex N. If the authentication of the UE is successful the S-CSCF shall associate the registration with the local state "tls-protected".

– When the P-CSCF receives message SM11 (200 OK) it shall associate the UE’s IP address and port of the TLS connection with the TLS Session ID, the IMPI and all the successfully registered IMPUs related to that IMPI. From this point on, the P-CSCF shall not accept any SIP signalling messages outside the TLS connection other than messages relating to emergency services in accordance with TS 24.229 [8] and TS 23.167 [31].

– After the UE has received SM12 it shall not accept any SIP signalling messages outside the TLS connection other than messages relating to emergency services in accordance with TS 24.229 [8] and TS 23.167 [31].

NOTE 3: The S-CSCF may have a local security policy to treat messages other than initial REGISTER messages, messages relating to emergency services, and error messages, differently depending on whether the registration is associated with the state "tls-protected".