6.2.19 End-to-end security for TCP based media using TLS
23.3333GPPMultimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface: Procedures descriptionsRelease 17TS
6.2.19.1 General
The MRFC and the MFRP may support e2e protection of TCP based media using the pre-shared key ciphersuites for TLS (specified in IETF RFC 4279 [34]) and the MIKEY-TICKET mechanism (specified in IETF RFC 6043 [33] with the profiling of tickets and procedures given in 3GPP TS 33.328 [31]).
The following clauses describe extensions to the Mp signalling procedures and their interactions with SIP signalling in control plane and with user plane procedures if the e2e security for TCP based media using TLS and KMS is supported by the MRFC and the MFRP.
6.2.19.2 Specific procedures for session based messaging (MSRP)
6.2.19.2.1 IMS UE originating procedures ("dial-in" scenario) for e2e
Figure 6.2.19.2.1.1 shows a "dial-in" conference procedure for one MSRP session using TLS and KMS based security.
NOTE: In the shown example it is assumed that the UE-A and the MRFC/MRFP support IETF RFC 6714 [40].
Figure 6.2.19.2.1.1: UE connecting into a messaging conference – example call flow for e2e case
The IMS UE-A and the MRFC perform an IMS conference session set-up according to 3GPP TS 23.228 [1], 3GPP TS 24.247 [17] and with modifications described in 3GPP TS 33.328 [31]. The procedure in the figure 6.2.19.2.1.1 for requesting e2e security for a media stream is described step-by-step with an emphasis on the additional aspects for the MRFC and the MRFP of the e2e media protection using TLS and KMS.
1. Depending on the KMS and a local policy, the IMS UE-A will either interact with the KMS to obtain keys and a MIKEY-TICKET ticket usable for the MRFC, or it will create the ticket by itself.
The IMS UE-A generates the TRANSFER_INIT message according to IETF RFC 6043 [33] containing the ticket associated with the MRFC. A single Crypto Session is included in the TRANSFER_INIT message as described in Annex H.3 of 3GPP TS 33.328 [31]. The protocol type in the Crypto Session is set to TLS.
The IMS UE-A creates an SDP offer with an MSRP based media over TLS transport protocol and inserts "a=setup:actpass" SDP attribute specified in IETF RFC 4145 [36] and key management protocol "a=key-mgmt" SDP attribute specified in IETF RFC 4567 [35] which indicates use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message encapsulated in a keymgmt-data field.
2. The IMS UE-A sends the SIP INVITE request with the SDP offer.
3. Upon reception of the SIP INVITE request with the SDP offer containing a media stream that uses "TCP/TLS/MSRP" transport protocol, the MRFC checks for the presence of the key management protocol "a=key-mgmt" SDP attribute. If it indicates the usage of the MIKEY the MRFC extracts a key management data from a keymgmt-data field and "base64" decodes them to reconstruct the original TRANSFER_INIT message. The MRFC checks if it is authorized to resolve the ticket and if that is the case the MRFC interacts with the KMS to resolve the ticket and receive keys.
4. – 6. The MRFC uses the "Reserve And Configure IMS resources" procedure to request a termination for "TCP/TLS/MSRP" media. The MRFC provides an IP address and port received from the IMS UE-A and includes a Pre-Shared Key information element containing the derived PSK i.e. the Traffic-Encrypting Key associated with the Crypto Session that will be used by the MRFP in TLS handshake. The MRFC includes a Notify TCP connection establishment Failure Event information element to request the MRFP to report an unsuccessful TCP connection set-up and a Notify TLS session establishment Failure Event information element to request the MRFP to report an unsuccessful TLS session set-up. In accordance to the information in the "a=setup" SDP attribute that will be sent in an SDP answer the MFRC requests the MRFP to start a TCP connection establishment and to start a TLS session once the TCP connection is established.
7. The MRFP sends a TCP SYN message towards the IMS UE-A to establish a TCP connection. The IMS UE-A answers with a TCP SYN ACK message and the MRFP replies with a TCP ACK message, completing the TCP connection establishment.
8. Upon completion of the TCP connection establishment, the MRFP starts a TLS session establishment using the received Pre-Shared Key information element to set-up a TLS-PSK tunnel to protect MSRP messages.
9. The MRFC includes the MIKEY-TICKET response in the TRANSFER_RESP message created according to IETF RFC 6043 [33]. The MRFC inserts the key management protocol "a=key-mgmt" SDP attribute which indicates use of the MIKEY-TICKET ticket and contains the "base64" encoded TRANSFER_RESP message. The TRANSFER_RESP message includes the information required for the generation of keys.
10. The MRFC sends the SIP 200 (OK) final response (or 18x provisional response) to the SIP INVITE request with the SDP answer to the IMS UE-A.
After receiving the SIP 200 (OK) final response (or 18x provisional response) to the SIP INVITE request with the SDP answer the IMS UE-A extracts a key management data from the keymgmt-data field and "base64" decodes them to reconstruct the original TRANSFER-RESP message. The IMS UE-A verifies the TRANSFER-RESP message according to IETF RFC 6043 [33] and then verifies that the authenticated identity of the recipient corresponds to the policy for the MSRP session before completing the media security set-up.
6.2.19.2.2 IMS UE terminating procedures ("dial-out" scenario) for e2e
Figure 6.2.19.2.2.1 shows a "dial-out" conference procedure for one MSRP session using TLS and KMS based security.
NOTE: In the shown example it is assumed that the UE-B and the MRFC/MRFP support IETF RFC 6714 [40].
Figure 6.2.19.2.2.1: Terminating ("dial-out") example call flow for e2e case
The MRFC and the IMS UE-B performs an IMS "dial-out" conference session set-up according to 3GPP TS 23.228 [1], 3GPP TS 24.147 [4] and with modifications described in 3GPP TS 33.328 [31].
The procedure in the figure 6.2.19.2.2.1 for requesting e2e security for a media stream is described step-by-step with an emphasis on the additional aspects for the MRFC and the MRFP of the e2e media protection using TLS and KMS.
1. The MRFC receives a trigger to create an ad-hoc conference. Depending on the KMS and a local policy, the MRFC will either interact with the KMS to obtain keys and a MIKEY-TICKET ticket usable for the IMS UE-B, or it will create the ticket by itself. In the latter case, MIKEY-TICKET mode 3 as specified in IETF RFC 6043 [33] is used, and the MRFC will then perform all key and ticket generation functions otherwise performed by the KMS.
The MRFC generates the TRANSFER_INIT message according to IETF RFC 6043 [33]. The identities of the initiator and the responder in the message are the KMS user identities derived from the URI’s in the To and From header fields in the SIP INVITE request.
A single Crypto Session is included in the TRANSFER_INIT message as described in Annex H.3 of 3GPP TS 33.328 [31]. The protocol type in the Crypto Session is set to TLS.
2. – 4. The MRFC uses the "Reserve IMS resources" procedure to request a termination for "TCP/TLS/MSRP" media towards the IMS UE-B.
5. The MRFC creates an SDP offer with an MSRP based media over TLS transport protocol and inserts the "a=setup:actpass" SDP attribute specified in IETF RFC 4145 [36] and the key management protocol "a=key-mgmt" SDP attribute specified in IETF RFC 4567 [35] which indicates the use of the MIKEY-TICKET ticket and contains the TRANSFER_INIT message encapsulated in a keymgmt-data field.
6. The MRFC sends the SIP INVITE request with the SDP offer to the IMS UE-B.
7. Upon reception of the SIP INVITE request with the SDP offer containing a media stream that uses transport "TCP/TLS/MSRP", the IMS UE-B checks if it is authorized to resolve a ticket and if that is the case the IMS UE-B interacts with the KMS to resolve the ticket and receive keys.
8. The IMS UE-B includes the MIKEY-TICKET response in the TRANSFER_RESP message created according to IETF RFC 6043 [33]. The IMS UE-B inserts the key management protocol "a=key-mgmt" SDP attribute specified in IETF RFC 4567 [35].
The IMS UE-B sends the SIP 200 (OK) final response (or 18x provisional response) to the SIP INVITE request with an SDP answer.
9. – 11. After receiving the SIP 200 (OK) final response (or 18x provisional response) to the SIP INVITE request with the SDP answer the MRFC extracts a key management data from the keymgmt-data field and "base64" decodes them to reconstruct the original TRANSFER-RESP message. The MRFC verifies the TRANSFER-RESP message according to IETF RFC 6043 [33] and then verifies that the authenticated identity of the recipient corresponds to the policy for the MSRP session before completing the media security set-up.
The MRFC uses the "Configure IMS resources" procedure to configure a termination towards the IMS UE-B with an IP address and port received from the IMS UE-B and includes a Pre-Shared Key information element containing the derived PSK i.e. the Traffic-Encrypting Key associated with the Crypto Session that will be used by the MRFP in TLS handshake. The MRFC includes a Notify TCP connection establishment Failure Event information element to request reporting of an unsuccessful TCP connection set-up and a Notify TLS session establishment Failure Event information element to request reporting of un unsuccessful TLS session set-up.
12. The IMS UE-B sends a TCP SYN message towards the MRFP to establish a TCP connection. The MRFP answers with a TCP SYN ACK message and the IMS UE-B replies with a TCP ACK message, completing the TCP connection establishment.
13. Upon completion of the TCP connection establishment, the IMS UE-B starts a TLS session establishment using the received Pre-Shared Key information element to set-up a TLS-PSK tunnel to protect MSRP messages.
6.2.19.3 Specific procedures for Floor Control Service (BFCP)
6.2.19.3.1 IMS UE requesting e2e protected Floor control connection
Figure 6.2.19.3.1.1 shows a "dial-in" conference procedure for one BFCP session with an e2e media protection using TLS and KMS based security.
Figure 6.2.19.3.1.1: UE requesting Floor control connection with FCS/MRFP – example call flow for e2e case
The IMS UE-A wants to establish a Floor control connection with a Floor Control Server (FCS), located in the MRFP. The IMS UE-A and the MRFC perform a Floor control connection set-up according to 3GPP TS 23.228 [3], 3GPP TS 24.147 [21] and with modifications described in 3GPP TS 33.328 [2].
The procedure in the figure 6.2.19.3.1.1 for requesting e2e security of the Floor control connection is described step-by-step with an emphasis on the additional aspects for the MRFC and the MRFP of the e2e media protection using TLS and KMS.
1. As step 1 in clause 6.2.19.2.1.
2. As step 2 in clause 6.2.19.2.1 with the exception that SDP offer indicates "TCP/TLS/BFCP" as transport protocol.
3. As step 3 in clause 6.2.19.2.1.
4. – 6. The MRFC uses the "Configure BFCP Termination" procedure to request a termination for "TCP/TLS/BFCP" media. The MRFC provides an IP address and port received from the IMS UE-A and includes a Pre-Shared Key information element containing the derived PSK i.e. the Traffic-Encrypting Key associated with the Crypto Session that will be used by the MRFP in TLS handshake. The MRFC includes a Notify TCP connection establishment Failure Event information element to request the MRFP to report an unsuccessful TCP connection set-up and a Notify TLS session establishment Failure Event information element to request the MRFP to report an unsuccessful TLS session set-up. In accordance to the information in the "a=setup" SDP attribute that will be sent in an SDP answer the MFRC requests the MRFP to start a TCP connection establishment.
7. As step 7 in clause 6.2.19.2.1.
8. As step 9 in clause 6.2.19.2.1.
9. As step 10 in clause 6.2.19.2.1 with the exception that the SDP answer indicates "TCP/TLS/BFCP" as transport protocol.
10. Upon completion of the TCP connection establishment and the reception of the SDP answer with a key management data, the IMS UE-A starts a TLS session establishment, in accordance to IETF RFC 4583 [21], using the received PSK to set-up a TLS-PSK tunnel to protect MSRP messages.
6.2.19.4 TLS session establishment Failure Indication
The MRFP shall use a Notify TLS session establishment Failure Indication procedure to report TLS session establishment related failures.
The figure 6.2.19.4.1 shows the message sequence chart example when the MRFP reports an unsuccessful TLS session set-up to the MRFC.
Figure 6.2.19.4.1: TLS session establishment Failure Indication