[VOIPSEC] Key Negotiation for SRTP
dwing at cisco.com
Thu Aug 25 18:54:31 PDT 2005
> I don't think sdescriptions is like MIKEY. I think
> sdescriptions puts the plaintext crypto parameters in an SDP
> attribute and needs to be protected using S/MIME, TLS, or
Right. sdescriptions is also much simplier than MIKEY; MIKEY
has an additional state machine for MIKEY itself.
Also, for two endpoints to interoperate with MIKEY, both
endpoints must also use the same MIKEY mode: RSA, DH, pre-shared
keys, or whichever other MIKEY modes are added. I suppose an
offer could include all of the various modes, but that adds even
more CPU overhead to originating a call and you're already
noticing the overhead of a single DH operation in a CPU-
> Thus, it is more like No. 4 below.
(I'm one of the coauthors of -sdescriptions-.)
> Have you (or anyone else) implemented S/MIME and does it have
> the same answer-after=0 problem you describe?
> Christian Stredicke wrote:
> >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?
> >Rhetorical question...
> >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
> >answer-after=0 problem?
> >Voipsec mailing list
> >Voipsec at voipsa.org
> Voipsec mailing list
> Voipsec at voipsa.org
More information about the Voipsec