Network Working Group J. Preuss Mattsson Internet-Draft M. Westerlund Obsoletes: 4568 (if approved) Ericsson Updates: 7201 (if approved) July 12, 2021 Intended status: Standards Track Expires: January 13, 2022 SDP Security Descriptions is NOT RECOMMENDED and Historic draft-mattsson-dispatch-sdes-dont-dont-dont-00 Abstract 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. 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." Preuss Mattsson & WesterExpires January 13, 2022 [Page 1] Internet-Draft SDES don't don't don't July 2021 This Internet-Draft will expire on January 13, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Status Change . . . . . . . . . . . . . . . . . . . . . . . . 4 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Normative References . . . . . . . . . . . . . . . . . . 5 3.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 Preuss Mattsson & WesterExpires January 13, 2022 [Page 2] Internet-Draft SDES don't don't don't July 2021 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. o 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. o 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. o 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. o 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. o 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." Preuss Mattsson & WesterExpires January 13, 2022 [Page 3] Internet-Draft SDES don't don't don't July 2021 o 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. o [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. o 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. 1.1. Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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. Preuss Mattsson & WesterExpires January 13, 2022 [Page 4] Internet-Draft SDES don't don't don't July 2021 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. 3. References 3.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . Preuss Mattsson & WesterExpires January 13, 2022 [Page 5] Internet-Draft SDES don't don't don't July 2021 [RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, . [RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices for Securing RTP Media Signaled with SIP", BCP 228, RFC 8862, DOI 10.17487/RFC8862, January 2021, . 3.2. Informative References [ANSSI] Agence nationale de la securite des systemes d'information, ., "Security Recommendations for TLS", January 2017, . [Baiting-SDES] Seokung Yoon, ., Jongil Jeong, ., and . Hyuncheol Jeong, "A Study on the Tightening the Security of the Key Management Protocol (RFC4568) for VoIP", June 2010, . [Hacking-SDES] Anthony Critelli, ., "Hacking VoIP: Decrypting SDES Protected SRTP Phone Calls", June 2014, . [Heist] The Intercept, ., "How Spies Stole the Keys to the Encryption Castle", February 2015, . [I-D.ietf-emu-aka-pfs] Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", draft-ietf-emu-aka-pfs-05 (work in progress), October 2020. [I-D.kaplan-sip-baiting-attack] Kaplan, H., Wing, D., and I. Property, "The SIP Identity Baiting Attack", draft-kaplan-sip-baiting-attack-02 (work in progress), February 2008. Preuss Mattsson & WesterExpires January 13, 2022 [Page 6] Internet-Draft SDES don't don't don't July 2021 [Replay-SDES] Prateek Gupta, . and . Vitaly Shmatikov, "Security Analysis of Voice-over-IP Protocols", June 2007, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC5411] Rosenberg, J., "A Hitchhiker's Guide to the Session Initiation Protocol (SIP)", RFC 5411, DOI 10.17487/RFC5411, February 2009, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, . [RFC8871] Jones, P., Benham, D., and C. Groves, "A Solution Framework for Private Media in Privacy-Enhanced RTP Conferencing (PERC)", RFC 8871, DOI 10.17487/RFC8871, January 2021, . [T3GPP.33.210] 3GPP, ., "TS 33.210 Network Domain Security (NDS); IP network layer security", July 2020, . [T3GPP.33.328] 3GPP, ., "TS 33.328 IP Multimedia Subsystem (IMS) media plane security", April 2021, . Preuss Mattsson & WesterExpires January 13, 2022 [Page 7] Internet-Draft SDES don't don't don't July 2021 Acknowledgements The authors want to thank Bo Burman and Christer Holmberg for their valuable comments and feedback. Authors' Addresses John Preuss Mattsson Ericsson Email: john.mattsson@ericsson.com Magnus Westerlund Ericsson Email: magnus.westerlund@ericsson.com Preuss Mattsson & WesterExpires January 13, 2022 [Page 8]