100 likes | 215 Views
Best Effort SRTP. Phil Zimmermann <prz@mit.edu> Alan Johnston <alan@sipstation.com>. 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. :-(
E N D
Best Effort SRTP Phil Zimmermann <prz@mit.edu> Alan Johnston <alan@sipstation.com> rtpsec BOF IETF-66
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
Without Best Effort Call Flow Secure UA Non-Secure UA INVITE m=SAVP 400 Not Supported ACK Failed Session! rtpsec BOF IETF-66
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
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
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
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
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
In-Band Discovery Flow Signaling Exchange RTP with secure flag RTP with secure flag Key Negotiation SRTP rtpsec BOF IETF-66
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