1. July 10, 2006rtpsec BOF IETF-661 Best Effort SRTP Phil Zimmermann Alan Johnston

2. July 10, 2006rtpsec BOF IETF-662 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 :-(

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

4. July 10, 2006rtpsec BOF IETF-664 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

5. July 10, 2006rtpsec BOF IETF-665 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

6. July 10, 2006rtpsec BOF IETF-666 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

7. July 10, 2006rtpsec BOF IETF-667 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

8. July 10, 2006rtpsec BOF IETF-668 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.

9. July 10, 2006rtpsec BOF IETF-669 In-Band Discovery Flow Signaling Exchange RTP with secure flag Key Negotiation SRTP

10. July 10, 2006rtpsec BOF IETF-6610 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