Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.334  Word version:  17.2.0

Top   Top   Up   Prev   Next
1…   4…   5…   5.11…   5.12…   5.14…   5.18…   5.19…   5.20…   5.21…   6…   6.1.6…   6.1.11…   6.2…   6.2.10…   6.2.10.3.1.2   6.2.10.3.2   6.2.10.4…   6.2.10.4.3…   6.2.10.5   6.2.10.6…   6.2.10A…   6.2.13…   6.2.14…   6.2.14.3   6.2.14.4…   6.2.15…   6.2.17…   6.2.17.3…   6.2.17.5…   6.2.18…   6.2.20   6.2.21…   6.2.22…   6.2.22.3…   6.2.22.3.2   6.2.23   6.2.24   6.2.25   7   8…   8.3   8.4   8.5…   8.23… 
5.11 IMS Media Plane Security  5.11.1 General  5.11.2 End-to-access-edge Security  5.11.2.1 End-to-access-edge security for RTP based media using SDES  5.11.2.2 End-to-access-edge security for TCP based media using TLS  5.11.2.3 End-to-access-edge security for UDP based media using DTLS  5.11.2.4 End-to-access-edge security for RTP based media using DTLS-SRTP  5.11.2.5 End-to-access-edge security for RTP based voice and video media using DTLS-SRTP over TCP  5.11.2.6 End-to-access-edge security for WebRTC data channels using UDP/DTLS/SCTP transport  5.11.3 End-to-end Security  5.11.3.1 End-to-end security for RTP based media  5.11.3.2 End-to-end security for TCP-based media using TLS 
...

 

5.11  IMS Media Plane Security  p. 22

5.11.1  General  p. 22

The IMS-ALG and the IMS-AGW may support IMS media plane security as specified in TS 33.328. They may support end-to-access edge security, or end-to-end security, or both, for
  • RTP based media (such as e.g. audio, video information) using SRTP security, and/or
  • TCP based media (such as MSRP and BFCP) using TLS security; and/or
  • UDP based media (such as T.38 fax over UDPTL/UDP) using DTLS security.
If supported the IMS-ALG and the IMS-AGW shall use the procedures in the following clauses.
Procedures for the IMS-ALG to determine if end-to-access edge security or end-to-end security is applicable to a session are specified in TS 33.328 and TS 24.229.
Up

5.11.2  End-to-access-edge Security  p. 22

5.11.2.1  End-to-access-edge security for RTP based media using SDES  p. 22

Procedures for the IMS-ALG to determine if end-to-access edge security is applicable to RTP based media and to exchange cryptography related SDP parameters with the served UE during the SIP session setup are specified in TS 33.328 and TS 24.229.
For media lines that can be subject to e2ae security, the IMS-ALG will receive "RTP/AVP" or "RTP/AVPF" as transport protocol in SDP from the core network. When the IMS-ALG determines that e2ae security is applicable, it will indicate "RTP/SAVP" (see RFC 3711) or "RTP/SAVPF" (see RFC 5124), respectively, as transport protocol in the corresponding SDP media lines send towards the served UE. When e2ae security is applied, the IMS-ALG will also receive "RTP/SAVP" or "RTP/SAVPF" in SDP from the served UE. The IMS-ALG will then indicate "RTP/AVP" or "RTP/AVPF" respectively, as transport protocol in the corresponding SDP media lines send towards the core network. When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for media to which e2ae security is applicable, the IMS ALG shall configure "RTP/SAVP" or "RTP/SAVPF" as transport protocol at the access side termination. The IMS ALG shall configure "RTP/AVP" or "RTP/AVPF" as transport protocol at the core network side termination for media where e2ae security is applicable.
When the IMS-ALG determines that e2ae security is applicable, it will generate appropriate cryptographic context parameters, in particular key(s), and will transfer them to the served UE within SDES SDP "crypto" attribute(s) according to RFC 4568. The IMS-ALG will also receive cryptographic context parameters, in particular key(s), from the served UE within SDES SDP "crypto" attribute(s). When the IMS-ALG requests the IMS-AGW to reserve or configure transport addresses/resources for media to which e2ae security is applicable, the IMS-ALG shall provide cryptography related parameters as SDES SDP "crypto" attributes applicable at the access side termination.
On the originating side of the SIP session setup, the IMS-ALG shall provide as "Remote cryptographic SDES attribute" the SDES crypto attribute it selected from the ones received from the IMS UE in the SDP Offer . The IMS-ALG shall provide as "Local cryptographic SDES attribute" the SDES crypto attribute the IMS-ALG generated and inserted in the SDP Answer sent to IMS UE.
On the terminating side of the SIP session setup, the IMS-ALG shall provide as "Remote cryptographic SDES attribute" the SDES crypto attribute received from the IMS UE in the SDP Answer. The IMS-ALG shall provide as "Local cryptographic SDES attribute" the SDES crypto attribute selected by the UE from the ones the IMS-ALG generated and inserted in the SDP Offer sent to UE. If the IMS-ALG offers only one SDES crypto attribute to the UE, the IMS-ALG may provide this attribute as "Local cryptographic SDES attribute" within the Reserve AGW Connection Point Procedure before receiving the SDP answer from the UE.In the present release, a modification of an established e2ae crypto session is not supported. Thus, the IMS-ALG shall not modify any previously provided "Local cryptographic SDES attribute" or "Remote cryptographic SDES attribute".
If the IMS-ALG applies e2ae media security for a media stream and receives an SDP bandwidth modifier related to that media stream in SIP/SDP signalling, it should modify this bandwith modifier to adjust the bandwidth overhead due to e2ae security before forwarding the SDP. The IMS-ALG should add the bandwidth overhead caused by e2ae media security to the bandwidth information received from the remote peer. The IMS-ALG should substract the bandwidth overhead caused by e2ae media security from the bandwidth information received from the served UE.
The IMS Access GW shall, upon reception of an SDES crypto attribute, establish an SRTP security context (as described in RFC 4568 and RFC 3711) and be prepared to convert RTP packets to SRTP packets and vice versa, using the corresponding SRTP security contexts.
Up

5.11.2.2  End-to-access-edge security for TCP based media using TLS |R12|  p. 23

5.11.2.2.1  General  p. 23
E2ae security for TCP based media using TLS is applicable for MSRP (see RFC 4975; used in IMS session-based messaging) and BFCP (see RFC 4582; used in IMS conferencing). The IMS-ALG and IMS-AGW may support e2ae security for MSRP, BFCP, or both protocols.
E2ae protection of MSRP and BFCP media is based on TLS, according to the TLS profile specified in Annex E of TS 33.310 and Annex M of TS 33.328. TLS shall be supported over the TCP transport (see RFC 793).
Key management for e2ae protection of MSRP and BFCP is based on the ciphersuites and session keys negotiated via the TLS handshake protocol between the UE and the IMS-AGW (see TS 33.328).
Procedures for the IMS-ALG to determine if e2ae security for MSRP and/or BFCP is applicable to a session and to exchange the cryptographic information (i.e. certificate fingerprints, see RFC 8122) over SDP with the served UE during the SIP session setup are specified in TS 33.328 and TS 24.229. If e2ae security is not required, the e2e security procedures may apply, see clause 5.11.3.
According to the TLS profile specified in Annex E of TS 33.310, the IMS-AGW shall accept TLS renegotiation only if it is secured according to RFC 5746.
If the IMS-ALG applies e2ae media security for a media stream and receives an SDP bandwidth modifier related to that media stream in SIP/SDP signalling, it should modify this bandwith modifier to adjust the bandwidth overhead due to e2ae security before forwarding the SDP. The IMS-ALG should add the bandwidth overhead caused by e2ae media security to the bandwidth information received from the remote peer. The IMS-ALG should substract the bandwidth overhead caused by e2ae media security from the bandwidth information received from the served UE.
For each MSRP or BFCP media stream to be set-up with e2ae security, the P-CSCF (IMS-ALG) shall:
  • include the IMS-AGW in the media path and allocate the required resources for the media stream in the IMS-AGW;
  • request a certificate fingerprint from the IMS-AGW;
  • include the certificate fingerprint received from the IMS-AGW in the SDP it sends to the IMS UE;
  • send the certificate fingerprint(s) received in the SDP from the IMS UE to the IMS-AGW;
  • instruct the IMS-AGW to perform state-aware TCP handling by including information about the TCP setup direction;
  • for each termination determine via SDP negotiation as specified in RFC 4145 if the IMS-AGW needs to act as TCP client or server for the terminations towards the core network and towards the access network;
  • indicate to the IMS-AGW how to perform the TCP connection establishment by:
    1. either instructing the IMS AGW to start a TCP connection establishment on any terminations where it needs to act as TCP client; or
    2. indicating to the IMS AGW to use an incoming TCP connection establishment request at one termination as a trigger to send a TCP connection establishment request at the interconnected termination in the same context (support of this alternative is optional for the IMS-AGW and IMS ALG);
  • determine via SDP negotiation if the IMS-AGW needs to act as TLS client or server as specified in the clauses below;
  • if the IMS-AGW needs to act as TLS client, request the IMS-AGW to start the TLS session setup once the TCP connection is established towards the UE; and
  • apply additional specific procedures for MSRP in clause 5.11.2.2.2 or for BFCP in clause 5.11.2.2.3.
For each MSRP or BFCP media stream to be set-up with e2ae security the IMS-AGW shall:
  • upon request from the IMS-ALG, select an own certificate for the media stream, uniquely associate own certificate with the media stream, and send the fingerprint of the own certificate to the IMS-ALG;
  • uniquely associate the certificate fingerprint(s) received from the IMS-ALG with the corresponding MSRP or BFCP media stream, and subsequently use the certificate fingerprint(s) (as described in RFC 4975) to verify the establishment of the TLS session of the corresponding media stream to belong to the served user;
  • if the verification of the remote certificate fingerprint(s) during the TLS session establishment fails, regard the remote TLS endpoint as not authenticated, terminate the TLS session and report the unsuccessful TLS session setup to the IMS-ALG;
  • negotiate the TLS protocol configurations with the TLS peer based on locally provisioned TLS profile parameters;
  • when the TLS session has been established, convert unprotected media received from the network to protected media to send to the served UE and vice versa;
  • be capable to support both the TLS server and TLS client roles;
  • when being instructed to start the TLS session setup, act as a TLS client and establish the TLS session as soon as the underlying TCP bearer connection is established;
  • upon instruction of the IMS-ALG to perform state-aware TCP handling, not forward any TCP connection establishment request received on one termination towards the interconnected termination;
  • upon corresponding instructions from the IMS ALG, start a TCP connection establishment on the indicated termination by sending a TCP SYN, or use an incoming TCP connection establishment request received at one termination as a trigger to send a TCP connection establishment request at the interconnected termination in the same context;
  • release the underlying TCP bearer connection as soon as the TLS session is released; and
  • apply additional specific procedures for MSRP in clause 5.11.2.2.2 or for BFCP in clause 5.11.2.2.3.
Up
5.11.2.2.2  e2ae security for session based messaging (MSRP)  p. 24
For each MSRP media stream outside WebRTC data channels requiring e2ae security, the IMS-ALG shall indicate to the IMS-AGW as transport protocol:
  1. for application-agnostic e2ae security support:
    • "TCP" at the termination towards the core network; and
    • "TCP/TLS" at the termination towards the access network; or
  2. for application-aware e2ae security support:
    • "TCP/MSRP" at the termination towards the core network; and
    • "TCP/TLS/MSRP" at the termination towards the access network.
The IMS-ALG shall determine via SDP negotiation if the IMS AGW needs to act as TLS client or TLS server using the RFC 4145 "a=setup" SDP attribute as follows:
  • if the IMS ALG send an "a=setup:active" SDP attribute in an SDP answer towards the UE, the IMS AGW shall act as TLS client;
  • if the IMS ALG send an "a=setup:passive" SDP attribute in an SDP answer towards the UE, the IMS AGW shall act as TLS server;
  • if the IMS ALG receives an "a=setup:active" SDP attribute in an SDP answer from the UE, the IMS AGW shall act as TLS server; and
  • if the IMS ALG receives an "a=setup:passive" SDP attribute in an SDP answer from the UE, the IMS AGW shall act as TLS client.
Up
5.11.2.2.3  e2ae security for conferencing (BFCP)  p. 25
For each BFCP media stream requiring e2ae security, the IMS-ALG shall indicate to the IMS-AGW as transport protocol:
  • "TCP" at the termination towards the core network; and
  • "TCP/TLS" at the termination towards the access network.
The IMS-ALG shall determine via SDP negotiation (see RFC 4583) if the IMS AGW needs to act as TLS client or TLS server as follows:
  • if the IMS ALG receives an initial SDP offer from the UE, the IMS AGW shall act as TLS server; and
  • if the IMS ALG sends an initial SDP offer towards the UE, the IMS AGW shall act as TLS client.
Up

5.11.2.3  End-to-access-edge security for UDP based media using DTLS |R12|  p. 25

5.11.2.3.1  General  p. 25
The IMS-ALG and the IMS-AGW may support end-to-access-edge (e2ae) security for an UDP based media. The e2ae protection of the UDP based media relies on the usage of DTLS, according to the DTLS profiles specified in Annex E of TS 33.310 and exchange of self-signed certificates as defined in TS 33.328.
Key management solution for the e2ae media security of UDP is based on the cipher suites and session keys negotiated via the DTLS handshake protocol between the served UE and the IMS-AGW as specified in TS 33.328. Procedures for the IMS-ALG to determine if e2ae security is applicable to UDP based media and to exchange the cryptographic information (i.e. certificate fingerprints, see RFC 8122) via SDP negotiation with the served UE during the SIP session establishment are specified in TS 33.328 and TS 24.229.
If the IMS-ALG applies e2ae media security for a media stream and receives an SDP bandwidth modifier related to that media stream in SIP/SDP signalling, it should modify this bandwith modifier to adjust the bandwidth overhead due to e2ae security before forwarding the SDP. The IMS-ALG should add the bandwidth overhead caused by e2ae media security to the bandwidth information received from the remote peer. The IMS-ALG should substract the bandwidth overhead caused by e2ae media security from the bandwidth information received from the served UE.
Clause 5.11.2.3.2 defines specific requirements for e2ae protection of T.38 fax media stream over UDPTL/UDP transport. The usage of UDPTL over DTLS is defined in RFC 7345 and RFC 8842.
Up
5.11.2.3.2  e2ae security for T.38 fax over UDP/UDPTL transport  p. 25
If the IMS-ALG and the IMS-AGW support e2ae security for the UDP based media using DTLS and certificate fingerprints, then for each T.38 fax media stream over UDPTL/UDP transport to be setup with e2ae security, the IMS-ALG shall:
  • include the IMS-AGW in the media path and allocate the required resources for the media stream in the IMS-AGW;
  • determine via SDP negotiation with the served UE if the IMS-AGW needs to act as DTLS client or DTLS server as specified in RFC 7345 and RFC 8842;
  • when requesting resources towards the access network:
    1. indicate to the IMS-AGW "UDP/DTLS" as transport protocol;
    2. send the certificate fingerprint(s) received from the served UE to the IMS-AGW; and
    3. request from the IMS-AGW the certificate fingerprint;
  • include the certificate fingerprint received from the IMS-AGW in the SDP body it sends to the served UE;
  • if the IMS-ALG received from the served UE an SDP offer with "a=tls-id" media-level SDP attribute (as specified in RFC 8842), create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the served UE;
  • if the IMS-ALG sends to the served UE an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer;
  • request the IMS-AGW to start the DTLS session setup if the IMS-AGW needs to act as DTLS client; and
  • when requesting resources towards the core network:
    1. indicate to the IMS-AGW "UDP" as transport protocol.
For each T.38 fax media stream over UDPTL/UDP transport to be setup with e2ae security, the IMS-AGW shall:
  • be capable to support both the DTLS server and DTLS client roles;
  • upon request from the IMS-ALG, act as DTLS client and start DTLS session establishment;
  • upon request from the IMS-ALG, select an own certificate for the T.38 fax media stream, uniquely associate its own certificate with the media stream, and send the fingerprint of the own certificate to the IMS-ALG;
  • uniquely associate the certificate fingerprint(s) received from the IMS-ALG with the corresponding T.38 fax media stream; and
  • verify during the subsequent DTLS handshake with the served UE (as described in RFC 7345 and RFC 8842) that the fingerprint of the certificate passed by the served UE during DTLS handshake matches the certificate fingerprint received from the IMS-ALG:
    1. if the verification fails, the IMS-AGW shall regard the remote DTLS endpoint as not authenticated, terminate the DTLS session and report the unsuccessful DTLS session setup to the IMS-ALG;
    2. otherwise, the IMS-AGW shall continue with DTLS session setup and when the DTLS session is established, the IMS-AGW shall be prepared to receive and convert unprotected media from the core network to the protected media to be sent to the served UE and vice versa.
Up

5.11.2.4  End-to-access-edge security for RTP based media using DTLS-SRTP |R12|  p. 26

Support of end-to-access edge security for RTP based media using DTLS-SRTP is mandatory for WebRTC sessions and optional for other SIP sessions.
The P-CSCF (IMS-ALG) and IMS-AGW provide end-to-access edge security by using DTLS-SRTP, where DTLS is used to establish keys for SRTP according to IETF RFC 5763, IETF RFC 8842 and IETF RFC 5764.
During the establishment of a WebRTC or SIP session, the IMS-ALG receives "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as the transport protocol in SDP from the served UE (IMS UE or WebRTC IMS Client (WIC)). The IMS-ALG then shall indicate "RTP/AVP" or "RTP/AVPF" over UDP, respectively, as the transport protocol in the corresponding SDP media lines send towards the core network. When an IMS-ALG receives "RTP/AVP" or "RTP/AVPF" in SDP from the core network, the IMS-ALG shall indicate "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol in SDP send towards the served UE (IMS UE or WIC). When the IMS-ALG requests the IMS-AGW to reserve transport addresses/resources for e2ae media security, the IMS ALG shall configure "UDP/TLS/RTP/SAVP" or "UDP/TLS/RTP/SAVPF" as transport protocol at the access side termination, and "RTP/AVP" or "RTP/AVPF" over UDP as transport protocol at the core network side termination.
The IMS-ALG shall send the received UE (IMS UE or WIC) certificate fingerprint(s) to the IMS-AGW that is then able to correlate the fingerprint within the media stream uniquely. For each SRTP/SRTCP media stream to be established with e2ae media security, the IMS-AGW shall send the fingerprint of its certificate via Iq interface to the IMS-ALG.
If the IMS-ALG received from the UE (IMS UE or WIC) an SDP offer with "a=tls-id" media-level SDP attribute (as specified in IETF RFC 8842), create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the UE (IMS UE or WIC).
If the IMS-ALG sends to the UE (IMS UE or WIC) an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer.
According to procedures defined in TS 24.229 and TS 24.371, the IMS-AGW shall act as either a DTLS server or client in the DTLS session.
In DTLS-SRTP case, RTP and RTCP data are encrypted using SRTP and SRTCP as defined in RFC 3711.
When the DTLS session is established between the UE (IMS UE or WIC) and the IMS-AGW, the IMS-AGW shall be prepared to send and receive SRTP/SRTCP packets of the incoming network side from the UE (IMS UE or WIC), and convert SRTP/SRTCP packets to RTP/RTCP packets to the outgoing network side and vice versa, if the media stream toward the IMS core network is using RTP/RTCP.
Up

5.11.2.5  End-to-access-edge security for RTP based voice and video media using DTLS-SRTP over TCP |R12|  p. 27

The eP-CSCF (IMS-ALG) and eIMS-AGW for WebRTC may support end-to-access-edge security for RTP based voice and video media using DTLS-SRTP over TCP. If they do so, they shall apply the procedures in the present clause.
TCP transport may be offered as an alternative to UDP transport using the ICE procedures in clause 5.18. The eP-CSCF (IMS-ALG) and eIMS-AGW for WebRTC shall then provide end-to-access edge security for voice and video by using DTLS-SRTP over TCP, where DTLS is used to establish keys for SRTP according to RFC 5763, RFC 8842 and RFC 5764. Framing according to RFC 4571 shall be used for RTP streams transferred over TCP.
The IMS-ALG shall send the received WIC certificate fingerprint(s) to the eIMS-AGW that is then able to correlate the fingerprint within the media stream uniquely. For each SRTP/SRTCP media stream to be established with e2ae media security, the eIMS-AGW shall send the fingerprint of its certificate via Iq interface to the IMS-ALG.
If the IMS-ALG received from the WIC an SDP offer with "a=tls-id" media-level SDP attribute (as specified in RFC 8842) create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP answer which the IMS-ALG sends to the WIC.
If the IMS-ALG sends to the WIC an SDP offer, create a new DTLS association identity and include the "a=tls-id" SDP attribute with the new DTLS association identity in the SDP offer.
According to procedures defined in TS 24.371, the eIMS-AGW shall act as either a DTLS server or client in the DTLS session.
In DTLS-SRTP over TCP case, RTP and RTCP data are encrypted using SRTP and SRTCP as defined in RFC 3711.
When the DTLS session is established between the WIC and the eIMS-AGW, the eIMS-AGW shall be prepared to send and receive SRTP/SRTCP packets over TCP of the incoming network side from the WIC, and convert SRTP/SRTCP packets to RTP/RTCP packets over UDP to the outgoing network side and vice versa, if the media stream towards the IMS core network is using RTP/RTCP over UDP.
Up

5.11.2.6  End-to-access-edge security for WebRTC data channels using UDP/DTLS/SCTP transport |R13|  p. 28

The procedures in clause 5.20.2 are applicable.

5.11.3  End-to-end Security  p. 28

5.11.3.1  End-to-end security for RTP based media |R12|  p. 28

For the support of e2e-security, the IMS-ALG and the IMS-AGW shall support "RTP/SAVP" (see RFC 3711) and/or "RTP/SAVPF" (see RFC 5124) as transport protocol.
If the IMS-ALG receives SDP containing media lines with "RTP/SAVP" (see RFC 3711) or "RTP/SAVPF" (see RFC 5124) as transport protocol, but did not receive any request for end-to-access-edge security, the IMS-ALG shall:
  • forward the SDP with unmodified transport protocol for those media lines;
  • provide "RTP/SAVP" or "RTP/SAVPF", as received in the SDP, to the IMS-AGW as transport protocol for all related terminations, and provide no media related information to these terminations, to configure the IMS-AGW to pass media transparently.
If the IMS-ALG receives SDP containing SDES SDP attribute(s) according to RFC 4568, and did not receive any request for end-to-access-edge security, it shall forward the SDP with unmodified SDES SDP attribute(s), but shall not provide the SDES SDP attribute(s) to the IMS-AGW.
Up

5.11.3.2  End-to-end security for TCP-based media using TLS |R12|  p. 28

End-to-end protection of MSRP (used in IMS session-based messaging) and BFCP (used in IMS conferencing) media is based on TLS, according to the TLS profile specified in Annex E of TS 33.310 and Annex M of TS 33.328.
If the IMS-ALG receives SDP containing media lines with "TCP/TLS/MSRP" (see RFC 4975 and RFC 6714) and/or "TCP/TLS/BFCP" (see RFC 4583) as transport protocol but did not receive any request for end-to-access-edge security, the IMS-ALG shall:
  • forward the SDP with unmodified transport protocol for those media lines and unmodified TLS related SDP attribute(s);
  • indicate "TCP" to the IMS-AGW as transport protocol for all related terminations, and provide no media related information to these terminations, to configure the IMS-AGW to pass media transparently.
Up

Up   Top   ToC