[VOIPSEC] Key Negotiation for SRTP

[Dan Wing]

> 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 
> similar.

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-
constrained device.

> Thus, it is more like No. 4 below.

Right.

(I'm one of the coauthors of -sdescriptions-.)

-d

> Have you (or anyone else) implemented S/MIME and does it have 
> the same answer-after=0 problem you describe? 
>
> Lucas
> 
> 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?
> >
> >
> >Christian
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >.
> >
> >  
> >
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org