SDP Security Descriptions is NOT RECOMMENDED and Historic

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 13 January 2022.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

Key exchange without forward secrecy enables pervasive monitoring [RFC7258]. Massive pervasive monitoring attacks relying on key exchange without forward secrecy have been reported [Heist] [I-D.ietf-emu-aka-pfs], 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 [RFC8447] in TLS 1.2 [RFC5246], and static RSA and DH are forbidden in TLS 1.3 [RFC8446]. A large number of TLS profiles forbid use of key exchange without Diffie-Hellman for TLS 1.2 [RFC7540], [ANSSI], [T3GPP.33.210]. SRTP deployments are severely lagging behind TLS deployments in this area as SDP Security Descriptions [RFC4568] 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 [RFC7258], Security Descriptions [RFC4568] has a number of additional significant security problems.¶

• As stated in [RFC7201], 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 [Replay-SDES] "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 [RFC4568] 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 [RFC4568] 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 [Baiting-SDES] the model of slitting the security between two independent layers is flawed, SDP Security Description is vulnerable to the Baiting attack [I-D.kaplan-sip-baiting-attack], and "This situation leads to security vulnerability and attacker could get master key by spoofing in unencrypted path."¶
• As Security Descriptions [RFC4568] transports cryptographic keys without confidentiality in Session Description Protocol, the media keys are available to any entity that has visibility to the SDP [RFC5411]. 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.¶
• [Hacking-SDES] 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 [RFC8827], PERC [RFC8871], and [RFC8862] do mandate support of DTLS-SRTP [RFC5764]. WebRTC also forbids support of SDP Security Descriptions.¶

• WebRTC [RFC8827] states (for good reasons) that "WebRTC implementations MUST NOT offer SDP security descriptions [RFC4568] 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 [T3GPP.33.328] 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 [T3GPP.33.328] 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.¶

2. Status Change

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 [RFC4568] is NOT RECOMMENDED. Existing deployments SHOULD mandate support of DTLS-SRTP [RFC5764] 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 [RFC4568]. This document reclassifies RFC 4568, SDP Security Descriptions to Historic Status and obsoletes RFC 4568.¶

As required by [RFC7258], work on IETF protocols needs to consider the effects of pervasive monitoring and mitigate them when possible.¶

Acknowledgements

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

Authors' Addresses