Ericsson

john.mattsson@ericsson.com

Ericsson

magnus.westerlund@ericsson.com

Key exchange without forward secrecy enables pervasive monitoring. Massive pervasive monitoring attacks relying on key exchange without forward secrecy have been reported, and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to long-term keys enable passive attackers to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. Session Description Protocol (SDP) Security Descriptions (RFC 4568) does not offer PFS and has a large number of additional significant security weaknesses. This document specifies that use of the SDP Security Descriptions is NOT RECOMMENDED. New deployments SHOULD forbid support of SDP Security Descriptions. This document reclassifies RFC 4568 (SDP Security Descriptions) to Historic Status and also obsoletes RFC 4568. This document updates RFC 7201 (Options for Securing RTP Sessions) to note that SDP Security Descriptions SHOULD NOT be used.

Key exchange without forward secrecy enables pervasive monitoring . Massive pervasive monitoring attacks relying on key exchange without forward secrecy have been reported , and many more have likely happened without ever being reported. If key exchange without Diffie-Hellman is used, access to long-term keys enables passive attackers to compromise past and future sessions. Entities can get access to long-term key material in different ways: physical attacks, hacking, social engineering attacks, espionage, or by simply demanding access to keying material with or without a court order. All TLS cipher suites without forward secrecy has been marked as NOT RECOMMENDED in TLS 1.2 , and static RSA and DH are forbidden in TLS 1.3 . A large number of TLS profiles forbid use of key exchange without Diffie-Hellman for TLS 1.2 , , . SRTP deployments are severely lagging behind TLS deployments in this area as SDP Security Descriptions is still used in many deployments. SDP Security Description is often referred to as SDES. In this document SDES refers to SDP Security Descriptions and not RTP source descriptions, which are also often referred to as SDES. In addition to the very serious weaknesses of not providing protection against key leakage and enabling passive monitoring , Security Descriptions has a number of additional significant security problems. As stated in , Security Descriptions is vulnerable to SSRC collisions, which leads to so called “two-time pad” attacks. This vulnerability is worse than using a 32-bit MAC for data integrity, as a “two-time pad” may lead to loss of both confidentiality and integrity. In addition to happening by itself with a non-negligible probability, the SSRC collision attack can also be triggered by an attacker. As stated in “The most serious attack is a replay attack on SDES, which causes SRTP to repeat the keystream used for media encryption, thus completely breaking transport-layer security.” The authors stress that the attack is practical in existing implementations: “We emphasize that our attack on SDES/SRTP is not a theoretical exercise.”. If SSRC are predictable, an attacker can also improve the probability by blocking SDP with non-colliding SSRCs. Security Descriptions requires use of an encapsulating data-security protocol on each hop in the path giving at best hop-by-hop security. This assumes that all the intermediaries are trusted and uncompromised. This is a very insecure and outdated security model that fails completely as soon as a single node in the path is compromised. While Security Descriptions requires use of an encapsulating data-security protocol, several deployed systems are known to use Security Descriptions without any encapsulating data-security protocol to protect the SDP messages. This means that any on-path attacker can decrypt the communication as well as modify and inject SRTP packets. A huge problem with SDP Security Descriptions is that the endpoints have no way of verifying if the path is protected or not. As explained in the model of slitting the security between two independent layers is flawed, SDP Security Description is vulnerable to the Baiting attack , and “This situation leads to security vulnerability and attacker could get master key by spoofing in unencrypted path.” As Security Descriptions transports cryptographic keys without confidentiality in Session Description Protocol, the media keys are available to any entity that has visibility to the SDP . The cryptographic keys are known to often end up in logs and data retention systems. These systems are often accessible by many more user accounts than Lawful Interception (LI) systems. summarizes the security of SDP Security Descriptions as “the false sense of security might be more dangerous than simply leaving your voice calls unencrypted.” New systems and recommendations like WebRTC , PERC , and do mandate support of DTLS-SRTP . WebRTC also forbids support of SDP Security Descriptions. WebRTC states (for good reasons) that “WebRTC implementations MUST NOT offer SDP security descriptions or select it if offered.” Many implementations, devices, and libraries support DTLS-SRTP. One deployment that supports DTLS-SRTP but still use SDP Security Descriptions is IMS Media Security where Security Descriptions is one option used for access protection. IMS Media Security with SDP Security Descriptions is typically used for VoWi-Fi (Voice over EPC-integrated Wi-Fi) calls which is commonly used by 4G and 5G phones as a backup to VoLTE (Voice over LTE) and VoNR (Voice over NR). However, IMS Media Security has already specified and mandated support of DTLS-SRTP for interworking with WebRTC. Allowing use of DTLS-SRTP also for other use cases than WebRTC interworking would therefore be a relatively small change.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

This document reclassifies RFC 4568 (SDP Security Descriptions) to Historic Status and also obsoletes RFC 4568. This document updates RFC 7201 (Options for Securing RTP Sessions) to note that SDP Security Descriptions SHOULD NOT be used. This document specifies that use of the SDP Security Descriptions is NOT RECOMMENDED. Existing deployments SHOULD mandate support of DTLS-SRTP and long-term phase out use of SDP Security Descriptions. If it is known by out-of-band means that the other party supports DTLS-SRTP, then SDP Security Descriptions MUST NOT be offered or accepted. If it is not known if the other party supports DTLS-SRTP, both DTLS-SRTP and SDP Security Descriptions and SHOULD be offered during a transition period. New deployments SHOULD forbid support of Security Descriptions . This document reclassifies RFC 4568, SDP Security Descriptions to Historic Status and obsoletes RFC 4568. As required by , work on IETF protocols needs to consider the effects of pervasive monitoring and mitigate them when possible.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK] This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK] The Real-time Transport Protocol (RTP) is used in a large number of different application domains and environments. This heterogeneity implies that different security mechanisms are needed to provide services such as confidentiality, integrity, and source authentication of RTP and RTP Control Protocol (RTCP) packets suitable for the various environments. The range of solutions makes it difficult for RTP-based application developers to pick the most suitable mechanism. This document provides an overview of a number of security solutions for RTP and gives guidance for developers on how to choose the appropriate security mechanism. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a number of changes to TLS and DTLS IANA registries that range from adding notes to the registry all the way to changing the registration policy. These changes were mostly motivated by WG review of the TLS- and DTLS-related registries undertaken as part of the TLS 1.3 development process.This document updates the following RFCs: 3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301. Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. The Session Initiation Protocol (SIP) is the subject of numerous specifications that have been produced by the IETF. It can be difficult to locate the right document, or even to determine the set of Request for Comments (RFC) about SIP. This specification serves as a guide to the SIP RFC series. It lists a current snapshot of the specifications under the SIP umbrella, briefly summarizes each, and groups them into categories. This memo provides information for the Internet community. This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. This document defines the security architecture for WebRTC, a protocol suite intended for use with real-time applications that can be deployed in browsers -- "real-time communication on the Web". This document describes a solution framework for ensuring that media confidentiality and integrity are maintained end to end within the context of a switched conferencing environment where Media Distributors are not trusted with the end-to-end media encryption keys. The solution builds upon existing security mechanisms defined for the Real-time Transport Protocol (RTP). This document identifies a potential SPIT and Phishing attack, which subverts the RFC 4474 SIP Identity and RFC 4916 Connected Identity mechanisms in a particular way. The attack is termed "Baiting", as it uses a RFC4474-signed call as the bait for malicious use. Ericsson Ericsson Ericsson Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP- AKA'. This prevents an attacker who has gained access to the long- term pre-shared secret in a SIM card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.

The authors want to thank Bo Burman and Christer Holmberg for their valuable comments and feedback.