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]