[VOIPSEC] Key Negotiation for SRTP

Lakshminath Dondeti ldondeti at qualcomm.com
Tue Aug 30 10:00:48 PDT 2005


Hi Christian,

On DTLS, my understanding is that there is no need for TLS or for that 
matter TCP to establish a DTLS channel.  There is a research paper on a 
protocol called secure UDP which uses TLS for key management and a UDP 
security encapsulation protocol.

Just to clarify, I am not taking any position on SIP/UDP vs SIP/TCP debate :-).

regards,
Lakshminath

At 07:13 PM 8/29/2005, Christian Stredicke wrote:
>More comments inline... CS
>
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti at qualcomm.com]
> > Sent: Monday, August 29, 2005 11:32 PM
> > To: Christian Stredicke; Voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Key Negotiation for SRTP
> >
> > Hi,
> >
> > Some notes inline:
> >
> > At 01:40 PM 8/27/2005, Christian Stredicke wrote:
> > > We have implemented TLS, SRTP and the DH mode of MIKEY. Our
> > > experience is that MIKEY as complicated as TLS, therefore my
> > > opinion is to skip the whole MIKEY stuff and go for
> > > sdescriptions secured by using a TLS transport layer (and
> > > get the NAT/fragementation problems solved on a silver
> > > tablet on top).
> >
> > MIKEY is definitely not as complicated as TLS.  MIKEY and TLS
> > do share authentication infrastructure requirements, crypto
> > algorithms, and they are both key management protocols (TLS
> > also has a security encapsulation layer).  TLS is a general
> > purpose key management protocol with ciphersuite negotiation,
> > rekeying, plus it supports security encapsulation.
> >
> >
> > > This approach has at least two big advantages:
> > >
> > > (1) Many people can use openssl to implement TLS, that should
> > > make it much easier to support it, AFAIK there is nothing
> > > comparable available for MIKEY.
> >
> > MIKEY is a newer protocol, but there is atleast 1 open
> > implementation: http://minisip.org/source/libmikey-0.4.0.tar.gz
> >
> > Others' source code is available as well.  I have also seen
> > at least 2 toolkits.
> >
> >
> > > (2) There is no CPU juice necessary when the phone must pick
> > > up the call immediately. Sounds like a silly problem, but it
> > > is a hard real-life experience problem. Embedded systems have
> > > to be careful with CPU bursts.
> >
> > If a device can do TLS, it has more than sufficient processing
> > power for MIKEY.
> >
>
>My point are the *bursts*. In an embedded system it is ok if it takes 10
>seconds to set up a TLS connection (for example, during registration).
>But when you want to accept an incoming connection *immediately*, every
>ms counts. Even if MIKEY is easier than setting up a TLS connection, one
>second CPU usage will be unacceptable.
>
> >
> > > IMHO the proxy/end-to-end concerns as not so serious. In real
> > > life, you will talk to your operator or office directly and you
> > > must trust him anyway. It is just like with the emails. If some
> > > day  end-to-end becomes necessary, you still have S/MIME.
> >
> > I am reading your example as signaling security is not an end-to-end
> > concern.  Do you think that we don't need bearer path security for
> > end2end voice communication? Ever?
> >
>
>We should have realized that transporting the SRTP key is *related* to
>security. Transporting the SRTP key is as problematic as transporting
>the IP address, the port, the codecs, the caller-ID, and other
>call-related information. For example, if you know the IP address and
>the port, you can easily start a DoS attack. Therefore, the key must be
>transported as secure as these other information.
>
>The transport *itself* can use existing mechanisms. TLS, DTLS, S/MIME,
>PGP/MIME, whatever. The key is here not to reinvent the wheel. If you
>have sensitive information (and the SRTP belongs to that group), use a
>secure transport mechanism. It is so simple.
>
> >
> > > Some people argue that SIP operators cannot move to TLS or even
> > > TCP. First thing I would say is get rid of your hobby software.
> > > Operators should upgrade their stuff and use TLS. If you operate
> > > an Email service without TLS today, you have a big customer
> > > leakage problem anyway. That will sooner or later also happen
> > > with SIP. Lets make it sooner and make everybody's life easier.
> >
> > The TCP and TLS argument is a different one, and one that I have
> > followed from a comfortable distance :-).  Q: Are you saying TCP is
> > needed for TLS?  There is DTLS now, so perhaps the reasoning should
> > be based on transport features and not security protocol
> > availability.
>
>Practically speaking, if you implement TLS in SIP you should have done
>TCP transport layer before.
>
>The DTLS proposal sounds nice from the outside; but if you check the
>draft, it says something like set up a TLS connection first. The guys
>that have to implement this are scrating their heads: What should this
>be good for? Ok, it might be possible to run a UDP-based service after
>negotiating the security stuff (so you can run millions of endpoint on
>one UDP socket). But you still have the pain of NAT and you have to
>implement TLS *plus* the DTLS-related stuff.
>
>If you have millions of customers registered to your service, you can
>afford to have a service that is supporting the same amount of TCP
>connections (give me a dollar for every connection and I make sure that
>you can run that service.-). You have to do something on the application
>or operating system side, but it is possible and it has been done. And I
>believe it is still much easier than having all the UDP related
>problems.
>
> >
> > Good discussions in this thread!
> >
> > best,
> > Lakshminath
> >
> >
> > >CS
> > >
> > > > -----Original Message-----
> > > > From: Voipsec-bounces at voipsa.org
> > > > [mailto:Voipsec-bounces at voipsa.org] On Behalf Of
> > Lakshminath Dondeti
> > > > Sent: Saturday, August 27, 2005 12:17 AM
> > > > To: Voipsec at voipsa.org
> > > > Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> > > >
> > > > A summary of my thoughts on this at the moment:
> > > >
> > > > There are really two standards-based options, and both
> > involve SDP.
> > > >
> > > > 1) sdescriptions:  Amounts to just sending the key in the
> > > > clear (base-64
> > > > encoded) via SDP, and so needs a secure channel.  There are
> > > > two options there again and one is hop-by-hop security using
> > > > TLS and the other is S/MIME.  The question in my mind is
> > > > whether sdescriptions is a long-term solution (more on
> > that later).
> > > >
> > > > 2) MIKEY via SDP (sdp-keymgmt I-D):  There are several
> > > > options, but it is not too difficult to distill them down.
> > > > I'd use one of the RSA options (I have further thoughts on
> > > > how to reconcile the one in the RFC and the one I am
> > > > co-authoring, but that is still being discussed.  We may have
> > > > written it in the I-D, otherwise contact me offline) and use
> > > > the amortization technique suggested in 3830 and use the PSK
> > > > mode where a PSK is already established (no need to manually
> > > > set up PSKs if you don't want to).
> > > >
> > > > There is also another dimension to this.  Granted
> > > > sdescriptions is a decent near-term solution to get going,
> > > > but when we think about the upgrade path, TLS, S/MIME are on
> > > > the horizon, and IMO MIKEY.
> > > >
> > > > If a deployment starts out with MIKEY-NULL, your upgrade path
> > > > is much simpler.
> > > >
> > > > Anyway,  hope that helps.
> > > >
> > > > best regards,
> > > > Lakshminath
> > > >
> > > >
> > > > _______________________________________________
> > > > Voipsec mailing list
> > > > Voipsec at voipsa.org
> > > > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> > > >
> > > >
> > > >
> >
> >
> >
> >





More information about the Voipsec mailing list