[VOIPSEC] Voipsec Digest, Vol 8, Issue 26

[Albert]

The gist of this interesting chain seems to be that the VOIP regulatory 
bodies must agree on a common set of encryption requirements, however bad, 
to get VOIP started

WIFI started out with WEP and that, while portable and cell-phones may use 
encrypted communication to the nearest base station, to my knowledge it is 
not compulsory everywhere 
Further, the encryption protocols and algorithms used for DECT and GSM do 
not appear to be too strong either.

Am I being too optimistic of the capabilities of the engineers designing 
VOIP security? ...

my EURO0,02 re the delay for key negotiation

I think that a 2-3 second delay in *setting up* a call is perfectly 
acceptable seeing the usual time it takes to establish any phone connection. 
In my mind it is analogous to the security checks at the airport before 
boarding the plane.

A 2-3 second interruption during a call is as unacceptable as a short stop 
in mid air for a security check. (sic. on the fly!)

I do not imagine voip suppliers to be so naive as to wait for the next key 
negotiation to be overdue before starting to calculate what is needed if 
periodic key changes are required to maintain a link.



2005/8/30, Voipsec-request at voipsa.org <Voipsec-request at voipsa.org>:
> Send Voipsec mailing list submissions to
> Voipsec at voipsa.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> or, via email, send a message with subject or body 'help' to
> Voipsec-request at voipsa.org
> 
> You can reach the person managing the list at
> Voipsec-owner at voipsa.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Voipsec digest..."
> 
> 
> Today's Topics:
> 
> 1. Re: Key Negotiation for SRTP (Ahmar Ghaffar) (Ahmar Ghaffar)
> 2. Re: Key Negotiation for SRTP (Dan Wing)
> 3. Re: Voipsec Digest, Vol 8, Issue 7 (Bill Flanagan)
> 4. Re: Key Negotiation for SRTP (Ahmar Ghaffar) (Johnston, Alan)
> 5. Re: Key Negotiation for SRTP (Lakshminath Dondeti)
> 6. Re: Key Negotiation for SRTP (Christian Stredicke)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 30 Aug 2005 13:41:29 +0200
> From: "Ahmar Ghaffar" <ghaffar at snom.de>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)
> To: <Voipsec at voipsa.org>
> Message-ID: <200508301137.j7UBbSeM023814 at post.webmailer.de>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Hello,
> 
> Some inline comments:
> 
> >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.
> 
> Its true that MIKEY is not "as" complicated as TLS, but it is also not
> something trivial. This is obvious from the very fact that none of the 
VoIP
> vendors is touching it. Besides the different modes available present a
> problem as far as interop is concerned. If vendor A implements mode X and
> vendor B implements mode Y, then we are back to square one. Using
> sdescriptions has the obvious advantage that the vendors who plan to
> implement TLS in the future but not right away, can still support
> sdescriptions without TLS and get things moving atleast.
> 
> >If a device can do TLS, it has more than sufficient processing power for
> MIKEY.
> 
> I agree but it's a question of context. You can afford latency for 
signaling
> via TLS, but imagine calling someone and having to wait 2-3 seconds before
> you hear the other person cuz your SIP phone is calculating the "shared
> secret". I would certainly be turned off by that.
> 
> 
> Rgds
> Ahmar
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 29 Aug 2005 16:22:08 -0700
> From: "Dan Wing" <dwing at cisco.com>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> To: "'Lakshminath Dondeti'" <ldondeti at qualcomm.com>, "'Christian
> Stredicke'" <Christian.Stredicke at snom.de>, <Voipsec at voipsa.org>
> Message-ID: <200508292322.QAA18716 at edison.cisco.com>
> Content-Type: text/plain; charset="us-ascii"
> 
> ...
> > >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?
> 
> Christian's last sentence seems to indicate he believes that end-to-end
> SDP encryption may become a necessity. At which time S/MIME can be used
> to provide that end-to-end encryption of SDP.
> 
> > >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?
> 
> Yes, RFC3261 says that today. There is draft-jennings-sip-dtls, but it
> isn't yet an RFC.
> 
> > There is DTLS now, so perhaps the reasoning should be based on
> > transport features and not security protocol availability.
> 
> To avoid fragmentation, large SIP messages are going to force us to TCP.
> DTLS doesn't handle large application-layer messages except by (a)
> fragmentation or by (b) pushing the problem to the application layer. Of
> course, SIP doesn't have any application-level fragmentation, so DTLS will
> cause fragmentation of these large SIP messages.
> 
> -d
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 30 Aug 2005 10:47:33 -0400
> From: Bill Flanagan <bill at flanagan-consulting.com>
> Subject: Re: [VOIPSEC] Voipsec Digest, Vol 8, Issue 7
> To: Voipsec at voipsa.org
> Message-ID: <43147185.2020806 at flanagan-consulting.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> Well said, Geoff.
> 
> My clients seldom understand how much VoIP differs fundamentally from the
> traditional TDM PBX. When contemplating VoIP on an existing data network, 
I
> usually need to point out the upgrades that will be needed to even 
approach the
> level of availability afforded by the cheapest key system or or miniPBX.
> 
> One of the most difficult aspects is getting router managers and engineers 
to
> count "scheduled maintenance" as an outage when it affects service. They 
would
> never accept such outages on their home phones--too risky in case of an
> emergency. Worse, it's not that they don't want the same availability for 
VoIP
> in the office, it's that they don't seem to connect that concept with 
taking
> routers and Ethernet switches out of service.
> 
> When was the last time you sent an email to the help desk because your 
phone was
> out?
> 
> Bill
> 
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Tue, 9 Aug 2005 08:49:43 -0400
> > From: "Geoff Devine" <gdevine at cedarpointcom.com>
> > Subject: [VOIPSEC] RE: TLS as the SIP security mechanism
> > To: <Voipsec at voipsa.org>
> > Message-ID:
> > <9CDE330E7358724EA30D93598D24DE4A010E5D at exchange.cedarpointcom.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > I think you fail to grasp the requirements of primary line telephony. 
The telephone network has been designed to avoid outages since it's good 
public policy to have telephone service available... even when the power 
goes out. In my voice over cable space, residential VoIP devices have 
battery backup. The network has battery backup and diesel generators. 
Everything is engineered so the core maintains five 9's up time. This is 
required so when someone needs telephone service in an emergency, they'll 
get dialtone.
> >
> > The telephone network is, of course, imperfect and doesn't achieve true 
five 9's at the core. If the intent hadn't been to engineer a five 9's 
system, it would certainly be an order of magnitude less stable than it is. 
If you design a network where you have restart avalanches after every bounce 
of a SIP proxy, you can't possibly achieve these objectives. You have a 
moral and ethical obligation to engineer them out.
> >
> > You ask why anyone would want to have hundreds of thousands of 
subscribers on a proxy? In my voice over cable space, you'd be laughed out 
the door if you didn't have a scaling story that looked like that with 
product that can do 100K today. Nobody wants to manage a wall of equipment 
racks full of machines to service a city. The operators don't have the space 
in the head end for all the equipment. Problems like restart avalanches 
certainly go away if you can limit a SIP proxy to 1000 subscribers but you 
wouldn't sell any in my space.
> >
> > Geoff
> >
> > ________________________________
> >
> --
> ____________________________________________
> William Flanagan Ph: +1.703.242.8381
> Flanagan Consulting Fx: +1.703.242.8391
> 45472 Holiday Dr. #3, Sterling, VA 20166 USA
> www.flanagan-consulting.com <http://www.flanagan-consulting.com>
> 
> "Beware of false knowledge; it is more dangerous than ignorance."
> --George Bernard Shaw
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 30 Aug 2005 16:21:21 +0000
> From: "Johnston, Alan" <alan.johnston at mci.com>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP (Ahmar Ghaffar)
> To: Mark Baugher <mbaugher at cisco.com>, Lakshminath Dondeti
> <ldondeti at qualcomm.com>
> Cc: Ahmar Ghaffar <ghaffar at snom.de>, Voipsec at voipsa.org
> Message-ID:
> <40AF35183B110B4899DD3221904B6B58045439A3 at usashms001.mcilink.com>
> Content-Type: text/plain; charset=us-ascii
> 
> <snip>
> 
> > It's like Waiting for Godot. Phil Zimmerman has an alternative
> > approach that does not require one. That's yet another way to key
> > SRTP, however.
> >
> 
> Hi Mark,
> 
> Phil Zimmermann's Zfone approach is quite different from MIKEY or SDES
> in that it doesn't even use the SIP signaling path for key management.
> 
> Instead, it does a DH exchange in RTP extension headers, much the same
> way that secure PSTN phones work today, using only the media path. To
> protect against a man-in-the-middle attack, a voice authentication
> digest is used. In addition, previous shared secrets are cached and
> used as input to generate a session key.
> 
> With this approach, no PKI is needed, and all the ugly backwards
> compatibility issues that Andy mentioned (which are really, really bad
> IMHO) are avoided. At the start of each call, the DH exchange is
> attempted - if it succeeds, both parties switch to SRTP using the
> session key and the users are informed that the session is now secure.
> If no, the call proceeds with RTP as normal.
> 
> Thanks,
> Alan Johnston
> sip:alan at sipstation.com
> 
> > Mark
> > >
> > >
> > >
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 30 Aug 2005 10:00:48 -0700
> From: Lakshminath Dondeti <ldondeti at qualcomm.com>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> To: "Christian Stredicke" <Christian.Stredicke at snom.de>,
> <Voipsec at voipsa.org>
> Message-ID: <6.2.2.1.2.20050830095648.02c37df0 at qcmail1.qualcomm.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> 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
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> 
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 30 Aug 2005 19:22:09 +0200
> From: "Christian Stredicke" <Christian.Stredicke at snom.de>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> To: "Lakshminath Dondeti" <ldondeti at qualcomm.com>,
> <Voipsec at voipsa.org>
> Message-ID:
> <B52FDDEC7CBE9D40B36FE900C9AD78B43BDC5B at merenge.intern.snom.de>
> Content-Type: text/plain; charset="us-ascii"
> 
> Looks like you are right! Interesting reading:
> http://crypto.stanford.edu/~nagendra/papers/dtls.pdf. They are even
> proposing it for RTP.
> 
> Aarrrggghhhh....
> 
> CS
> 
> > -----Original Message-----
> > From: Lakshminath Dondeti [mailto:ldondeti at qualcomm.com]
> > Sent: Tuesday, August 30, 2005 7:16 PM
> > To: Christian Stredicke; Voipsec at voipsa.org
> > Subject: RE: [VOIPSEC] Key Negotiation for SRTP
> >
> > 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
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> End of Voipsec Digest, Vol 8, Issue 26
> **************************************
>