1 / 10

Transitioning to Secure Media: Challenges and Solutions for SRTP Adoption

The adoption of Secure Real-Time Transport Protocol (SRTP) presents significant challenges for transitioning from non-secure to secure media. Issues include device compatibility, signaling mechanisms, and the need for backward compatibility during the transition. This document discusses potential strategies for ensuring that calls can succeed even when only some devices support secure media, including in-band discovery methods, signaling for authentication, and ways to negotiate RTP profiles. Addressing these challenges is crucial for a smooth adoption of SRTP in communication systems.

abel-casey
Télécharger la présentation

Transitioning to Secure Media: Challenges and Solutions for SRTP Adoption

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Best Effort SRTP Phil Zimmermann <prz@mit.edu> Alan Johnston <alan@sipstation.com> rtpsec BOF IETF-66

  2. Without Best Effort SRTP • I need to know if you support secure media before I send you an INVITE :-( • If I choose incorrectly, the session fails completely. :-( • If I you have three devices and only one supports secure media, when I call you securely, only that phone will ever ring. :-( • Adoption of SRTP will require a step function - everyone must simultaneously support it or else bad things will happen to the early adopters :-( rtpsec BOF IETF-66

  3. Without Best Effort Call Flow Secure UA Non-Secure UA INVITE m=SAVP 400 Not Supported ACK Failed Session! rtpsec BOF IETF-66

  4. Why is this true? • SRTP currently can only be used with the Secure RTP profile (SAVP) • SDP offer/answer can negotiate many things, but not RTP profiles • a=keymgt and a=crypto cannot be used with normal AVP m= media lines rtpsec BOF IETF-66

  5. Requirements • The ability to transition from few devices supporting secure media to (hopefully) all devices supporting secure media. • Caller is willing to accept a non-secure media session during this transition period • Caller does not need to know if callee supports secure media. • Work with forking and early media • Must be backwards compatible rtpsec BOF IETF-66

  6. Signaling Discovery Mechanisms • Approaches • Try to retrofit SDP to allow negotiation of RTP profiles • draft-andreasen-mmusic-sdp-capability-negotiation-00.txt • Allow SRTP key management attributes in AVP profiles • Signaling is used to indicate that SRTP might be used. • Signaling can be useful for authentication • E.g. exchange of certificate fingerprints or SAS • Issues • Backwards compatibility • Deprecation of SAVP profile • Complexity in resulting SDP rtpsec BOF IETF-66

  7. In-band Discovery Mechanism • In-band RTP approach • Used in ZRTP • draft-zimmermann-avt-zrtp-01.txt • Fits nicely with in-path key management approaches that solve the other keying problems (early media, forking, clipping, etc.) • Can still utilize signaling for authentication • Can be supplemented by signaling discovery • Issues • Encryption ability can be dependent on codec support • Offer/answer exchange complete (codec selected) prior to encryption negotiation • Codec could be renegotiated to allow encryption rtpsec BOF IETF-66

  8. In-Band Discovery • “Secure Flag” encoded in RTP packets sent at the start of a media session • Can’t just start sending non-RTP packets on RTP ports without knowing the other UA is capable of demultiplexing • Causes audio crashes • Natural place for layering reasons if in-path key management is used • Use the RTP Extension header field for proven backwards compatibility • Ignored by UAs that don’t understand it • Answered by UAs that do. rtpsec BOF IETF-66

  9. In-Band Discovery Flow Signaling Exchange RTP with secure flag RTP with secure flag Key Negotiation SRTP rtpsec BOF IETF-66

  10. Signaling Secure Media After the Fact • Any backwards compatible solution for Best Effort SRTP will involve initiating SRTP over a normal AVP m= media line • Could indicate secure media in other ways: • a=srtp attribute • “issecure” feature tag (signaled with Contact URI) • Or, a re-INVITE or UPDATE could be used to upgrade a media line from non-secure to secure. • SAVP m= line would be added and AVP m= line would be declined rtpsec BOF IETF-66

More Related