Best Effort SRTP
description
Transcript of Best Effort SRTP
July 10, 2006 rtpsec BOF IETF-66 1
Best Effort SRTP
Phil Zimmermann <[email protected]>
Alan Johnston <[email protected]>
July 10, 2006 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 :-(
July 10, 2006 rtpsec BOF IETF-66 3
Without Best Effort Call Flow
INVITE m=SAVP
400 Not Supported
ACK
Failed Session!
SecureUA
Non-SecureUA
July 10, 2006 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
July 10, 2006 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
July 10, 2006 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
July 10, 2006 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
July 10, 2006 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.
July 10, 2006 rtpsec BOF IETF-66 9
In-Band Discovery Flow
Signaling Exchange
RTP with secure flag
RTP with secure flag
Key Negotiation
SRTP
July 10, 2006 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