[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some views on Secure RTP


Hi Craig,
as one of the authors of DTLS-SRTP, I would be grateful to you if you could help me understand your thinking here; I also have a comment on ZRTP. 

On Mar 13, 2007, at 7:54 AM, Craig Southeren wrote:



To all,
I've been following the progress of secure RTP for some time, because I am interested in the technology and because my customers demand it. I 
thought I'd share my views now before the Prague IETF meeting in the
hope that perhaps they may be interest to those who make the decisions.
I'm seeing the same reasons over and over for why my customers prefer 
ZRTP.
I'm curious: who are your customers? Are they from a particular market segment? 


Frankly, I'm hard pressed to see why I should disagree.

1) ZRTP allows ad-hoc authentication without the need for a PKI. This
reduces the risk for enterprises as it does not require the installation 
of a time intensive and expensive PKI.
True enough for enterprises that feel that reading the short auth string (SAS) provides a satisfactory level of security. Would it be acceptable in the scenarios that you're addressing to use DTLS-SRTP and rely on reading the fingerprint to provide security? The one operational difference would be that the fingerprint is longer. (It is possible to add an SAS facility to TLS; Eric Rescorla and I have started that work and can bring it to the IETF if the consensus is that it is needed in DTLS-SRTP, so your opinion counts here :-) 


But, it can be upgraded easily to
use a PKI when and if required.
I respectfully disagree that it would be easy. Sure, the IETF understands certificates pretty well, but at present the draft only mentions signatures ("key types and signature algorithms are for future study") and has not considered certificates or any of the associated issues (for example, there are no identifiers in ZRTP that would naturally be used as the names in certificates and in authorizations associated with those certs).
2) Because it is contained completely within the RTP media channel, ZRTP can cross signalling protocol boundaries with no changes to the signalling 
infrastructure. Making a ZRTP call from a SIP endpoint to a H.323
endpoint is trivial even when the signalling entities do not have any
facility for including the additional messaging
I guess that this is one of the benefits of doing things in the media plane :-)
Is there a reason why this can't be done with DTLS-SRTP, assuming that the implementation negotiates RTP via signaling, but then attempts SRTP and falls back if the other side sends RTP? I believe that this will work (if not, I'd like to know what breaks), and Eric and I wrote our draft with that in mind. The reason that we didn't explicitly describe this in the draft was because it is not exactly clear that this behavior is considered desirable from a security viewpoint. If we can get buy-off from the responsible Security Area folks, I'm fine with adding it. 



3) The alternatives to ZRTP all seem to specify a dizzying array of
keying options that require changes to signalling channel which are
mostly "yet to be defined". As an example, the capabilities for H. 235.SRTP are nonsensically complex, and I'm still waiting for a clear leader for 
SIP keying.
I'm in the process of adding support for ZRTP into the OPAL open source 
infrastructure, where it will be available for SIP and H.323 calls. In
fact, as most of the changes are only in the RTP stack only, there are
applications that will get ZRTP support simply because the use the OPAL 
RTP stack, even though they use other signalling protocols.
Do you think that code re-use of TLS would be useful? Those signaling protocols use [D]TLS to provide their security, and I believe that openh323 uses openssl. There is a DTLS-SRTP implementation in a contrib branch of openssl (it compiles with libsrtp); I'd be happy to point it out to you if you want to check out it. 

best regards,

David



The integration using Phils SDK has been mostly smooth sailing so far.
The only limiting factor so far as been my available time :)

   Craig
---------------------------------------------------------------------- - Craig Southeren Post Increment – VoIP Consulting and Software craigs@xxxxxxxxxxxxxxxxxxxx www.postincrement.com.au 

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren@xxxxxxxxxxx
 Mobile: +61 417231046      Jabber: craigs@xxxxxxxxxx

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting