Rel-9 MEDIASEC work resulted in the specification of solutions for media protection over the access network (e2m) and peer-to-peer (e2e)
TS 33.328. For the peer-to-peer (e2e) media plane security, two solutions were standardized
-
A media security solution to satisfy major user categories.
-
A media security solution providing high quality end-to-end media security for important user groups like enterprises, National Security and Public Safety (NSPS) organizations and different government authorities.
However, the solutions do not cope with a number of requirements and relevant use cases of which many are discussed in
TR 33.828. Solutions for use cases like conference (group) calls, protection of non-RTP media, deferred delivery, video/media on demand, AS-terminated media security and transcoder functionality described in
TR 33.828 and some widely used use cases like recording of protected media, communication diversion, and single radio voice call continuity (SRVCC) have not been addressed. It is therefore desirable to continue to study and develop solutions for these use cases and to evaluate which normative standardization work that is needed.
The present document details relevant use cases/services for different user groups and corresponding solutions for IMS media plane security which are not covered by
TS 33.328. The corresponding requirements in the Rel-9 study documented in
TR 33.828 will be used as a basis. The covered use cases/services are: conference calls, protection of non-RTP media, early media, communication diversion, deferred delivery, protected media recording, video on demand, AS-terminated media security, transcoder functionality and SRVCC. Example user groups are enterprises, National Security and Public Safety (NSPS) organizations, different government authorities, and general public.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
-
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
-
For a specific reference, subsequent revisions do not apply.
-
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TR 33.828: "IP Multimedia Subsystem (IMS) media plane security".
[3]
TS 33.328: "IP Multimedia Subsystem (IMS) media plane security".
[4]
TS 24.147: "Conferencing using the IP Multimedia (IM), Core Network (CN) subsystem".
[5]
RFC 4583: "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams".
[6]
TS 24.605: "Conference (CONF) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[7]
TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2".
[8]
TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
[9]
TS 24.247: "Messaging service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3".
[10]
TS 29.311: "Service level interworking for Messaging Services".
[11]
TS 24.604: "Communication Diversion (CDIV) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification ".
[12]
RFC 3428: "Session Initiation Protocol (SIP) Extension for Instant Messaging".
[13]
RFC 4975: "The Message Session Relay Protocol (MSRP)".
[14]
[15]
RFC 6135: "An Alternative Connection Model for the Message Session Relay Protocol (MSRP)".
[16]
RFC 5365: "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)".
[17]
RFC 4575: "A Session Initiation Protocol (SIP) Event Package for Conference State".
[18]
RFC 6043: " MIKEY-TICKET: Ticket-Based Modes of Key Distribution in Multimedia Internet KEYing (MIKEY)".
[19]
RFC 3830: "MIKEY: Multimedia Internet KEYing".
[20]
RFC 5751: "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification".
[21]
RFC 5652: "Cryptographic Message Syntax (CMS)".
[22]
TS 33.310: "Network Domain Security (NDS); Authentication Framework (AF)".
[23]
RFC 4566: "SDP: Session Description Protocol".
[24]
RFC 4567: "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)".
[25]
RFC 4568: "Session Description Protocol (SDP) Security Descriptions for Media Streams".
[26]
TS 24.608: "Terminating Identification Presentation(TIP) and Terminating Identification Restriction (TIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification".
[27]
RFC 3264: "An Offer/Answer Model with the Session Description Protocol (SDP)".
[28]
RFC 6267: "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) ".
[29]
RFC 4771: "Integrity Transform Carrying Roll-Over Counter for the Secure Real-time Transport Protocol (SRTP)".
[30]
RFC 3550: "RTP: A Transport Protocol for Real-Time Applications".
[31]
RFC 3711: "The Secure Real-Time Transport Protocol".
[32]
GSM Association: "Rich Communication Suite 5.0 Advanced Communications, Services and Client Specification", Version 1.0, 19 April 2012
[33]
ITU-T recommendation T.38: "Procedures for real-time Group 3 facsimile communication over IP networks".
[34]
TS 26.114: "IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction".
[35]
RFC 4572: "Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP) ".
[36]
RFC 6347: "Datagram Transport Layer Security Version 1.2".
[37]
RFC 5763: "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS) ".
For the purposes of the present document, the terms and definitions given in
TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in
TR 21.905.
Key Escrow:
A key recovery technique for storing knowledge of a cryptographic key or parts thereof in the custody of a third party, so that the key can be recovered and used in specified circumstances. Key escrow can further be characterized as active or passive according to the way the knowledge of the key is obtained. In that sense, active key escrow actively participates and affects the generation of the cryptographic key, while passive key escrow learns of the cryptographic key and does not affect the generation of cryptographic key.
Perfect Forward Secrecy:
For a key agreement protocol, the property that compromising long-term keying material does not compromise session keys that were previously established using the long-term material.
For the purposes of the present document, the following symbols apply:
For the purposes of the present document, the abbreviations given in
TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in
TR 21.905.