[VOIPSEC] Key Negotiation for SRTP
cesc.santasusana at nl.thalesgroup.com
Thu Aug 25 16:44:08 BST 2005
Agreeing with you about SRTP being a good thing ... a pitty not well developed enough.
Securing sip is not easy, i think we all agree, but srtp plus a key management like mikey
makes it easier, and i think, actually usable. It also depends on your setup: you say you
favour number 4 ... but what if the middle proxies are not to be trusted?
Step by step:
Option 1 - agreed ... spooky. Only for testing purposes i would say.
Option 5 - wow ... i would say far too complex.
The other 3, i think they are all usable. I have tried mikey, with DH and TLS ... and i don't
think that the session establishment delay is a show-stopper. To "Joe Average", this latency
is not bigger than say the establishment of a cell phone call. You may want to speed up some
calculations for the DH algorithm on phone startup ... take a look at another MIKEY
You missed another option: tranport the Mikey message not inside the SDP message, but
over IPSec ESP.
I would favor some mixture between TLS and Mikey. Mikey allows for unencrypted messages to be
carried, for example, just authenticated. If stronger security is needed, use encrypted mikey over tls
(in the sdp message, say).
>>> "Christian Stredicke" <Christian.Stredicke at snom.de> 08/25/05 10:30AM >>>
Now SRTP is a RFC, this is great work and people would like to use this
in SIP dialog establishment.
I think there is a great degree of uncertainty how the key should be
exchanged. So far we have (correct me if there is something missing):
1. Statically provision the keys. Very simple, but practically
impossible and dangerous. "Goofy".
2. Use the mikey mechanism. Practically only the DH part should be
realistic. Problems here: We implemented this and found that is takes a
lot of CPU juice to answer a call immediately (e.g. answer-after=0). To
me that is a show-stopper.
3. draft-ietf-mmusic-sdescriptions-11.txt is more or less like mikey, I
was told. Should also have the answer-after=0 problem.
4. Use TLS and send the keys in clear text in the SDP. AN earlier
version of the Microsoft Messenger did this. Problems here: AFAIK only
snom supports TLS on hard phones so far. And the proxies will also be
able to see the keys (no end-to-end security). Or is it another reason
to finally really do TLS and solve a lot of other problems this way?
5. Using some INFO in the early dialog to re-negotiate the insecure
session into a secure one. No comment...
I would definitely favor 4.
Opinions? Pointers? Did I miss something here? Any experience with the
Voipsec mailing list
Voipsec at voipsa.org
More information about the Voipsec