Internet DRAFT - draft-mattsson-dispatch-sdes-dont-dont-dont
draft-mattsson-dispatch-sdes-dont-dont-dont
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc4568>.
[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,
<https://www.rfc-editor.org/info/rfc5764>.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
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,
<https://www.rfc-editor.org/info/rfc8447>.
[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,
<https://www.rfc-editor.org/info/rfc8862>.
3.2. Informative References
[ANSSI] Agence nationale de la securite des systemes
d'information, ., "Security Recommendations for TLS",
January 2017, <https://www.ssi.gouv.fr/uploads/2017/02/
security-recommendations-for-tls_v1.1.pdf>.
[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,
<http://phbo.janlo.nl/kpngips2/module-09/security-
analysis.pdf>.
[Hacking-SDES]
Anthony Critelli, ., "Hacking VoIP: Decrypting SDES
Protected SRTP Phone Calls", June 2014,
<https://www.acritelli.com/blog/hacking-voip-decrypting-
sdes-protected-srtp-phone-calls/>.
[Heist] The Intercept, ., "How Spies Stole the Keys to the
Encryption Castle", February 2015,
<https://theintercept.com/2015/02/19/great-sim-heist/>.
[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,
<http://phbo.janlo.nl/kpngips2/module-09/security-
analysis.pdf>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5411] Rosenberg, J., "A Hitchhiker's Guide to the Session
Initiation Protocol (SIP)", RFC 5411,
DOI 10.17487/RFC5411, February 2009,
<https://www.rfc-editor.org/info/rfc5411>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC8827] Rescorla, E., "WebRTC Security Architecture", RFC 8827,
DOI 10.17487/RFC8827, January 2021,
<https://www.rfc-editor.org/info/rfc8827>.
[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, <https://www.rfc-editor.org/info/rfc8871>.
[T3GPP.33.210]
3GPP, ., "TS 33.210 Network Domain Security (NDS); IP
network layer security", July 2020,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2279>.
[T3GPP.33.328]
3GPP, ., "TS 33.328 IP Multimedia Subsystem (IMS) media
plane security", April 2021,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=2295>.
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]
