July 10, 2006 rtpsec BOF IETF-66 1

Best Effort SRTP

Phil Zimmermann <prz@mit.edu>

Alan Johnston <alan@sipstation.com>

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