[VOIPSEC] Key Negotiation for SRTP

Mon Aug 29 21:13:24 CDT 2005

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