[VOIPSEC] Voipsec Digest, Vol 8, Issue 24

[Dan Wing]

> I've been watching this thread on STRP and have a couple of questions.
> It has been suggested that you could put a key in the sdp and 
> use TLS to
> encrypt.  My understanding is that TLS is essentially hop by hop and
> thus there is no guarantee that the security will be 
> maintained from end
> to end (particularly across administrative domains) - if one 
> hop is not
> encrypted you might as well send the whole thing in the 
> clear! 

That's like saying "my merchant has my credit card number
in the clear, so there isn't any reason to use TLS to send
them my credit card number."

> So what proposals are there to ensure end to end security of 
> the signaling path - or at least the SDP data without prior 
> arrangement with the receiving party?

If you're using sdescriptions, the proposal (which is part of 
base SIP already) is to use S/MIME.

If you're using MIKEY, the proposal is to use one of the MIKEY
modes that use DH or RSA.

Both proposals require a public key infrastructure.  None 
exists at this time.

-d


> Will
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Voipsec-request at voipsa.org
> Sent: Tuesday, August 30, 2005 6:00 AM
> To: Voipsec at voipsa.org
> Subject: Voipsec Digest, Vol 8, Issue 24
> 
> 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 (Zmolek, Andrew (Andy))
>    2. Re: Key Negotiation for SRTP (Lakshminath Dondeti)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Mon, 29 Aug 2005 10:03:02 -0600
> From: "Zmolek, Andrew \(Andy\)" <zmolek at avaya.com>
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> To: "Dan Wing" <dwing at cisco.com>,	"Christian Stredicke"
> 	<Christian.Stredicke at snom.de>,	"Ignjatic, Dragan"
> 	<Dragan.Ignjatic at polycom.com>,	"Lucas" <ljfisher at toadmail.com>
> Cc: Voipsec at voipsa.org, "Stegh, Christian S \(Chris\)"
> 	<cstegh at avaya.com>
> Message-ID:
> 	
> <EF4C65F18BE6464B8E9DF3C212B6B29307E749A5 at cof110avexu1.global.
> avaya.com>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> >From an implementability and reliable interoperability perspective,
> sdescriptions and INFO are the only real candidates in my 
> book (speaking
> from the perspective of an enterprise voice vendor). So far, the INFO
> method is a proprietary approach that doesn't have much of a shot at
> getting anything but an Informational RFC in the IETF but 
> does actually
> have a couple of interoperating vendors in the field. 
> 
> Yes, sdescriptions means that one has to rely on TLS or something else
> to secure the signaling channel. Some sanity checking has to 
> be done to
> make sure that the signaling channel isn't exposed. But mainstream
> vendors aren't going to implement a solution that has the potential of
> making the surrounding PKI so complex for their customers that it
> discourages them from going to encrypted voice in the first place. 
> 
> In any case, there's a huge security+interoperability problem 
> with VoIP
> today for the enterprise. One can purchase secure VoIP products and
> services or interoperable VoIP products and services but not 
> both. We've
> just wrapped up writing a brief article summarizing the protocols and
> interoperability gaps for VoIP Magazine (www.voip-magazine.com - not
> sure how quickly the article will be available online) but the bottom
> line is that neither H.323 nor SIP have a strong story there 
> right now.
> 
> For SIP in particular, there are actually two problems getting SRTP to
> work reliably between vendors. The first is the key management problem
> described in this thread. The other might be called "offer 
> management" -
> in other words, how can I offer SRTP in a way that's likely to be
> accepted by a compatible implementation without causing problems or
> delays in call processing for non-SRTP endpoints. So far, the most
> promising long-term solutions involve the use of multipart 
> MIME to make
> multiple offers but unfortunately there are a lot of endpoints that
> choke on multipart. 
> 
> In fact, it's this "offer management" problem that makes the 
> proprietary
> INFO method so attractive, since the SRTP negotiation doesn't start
> until the call is already underway. However, anyone with links to the
> IETF process will tell you that the INFO method is an abuse of the
> intent of that method. 
> 
> /\\//\Y/\   Andy Zmolek  |  zmolek at avaya.com  |  303-538-6040
>              GCS Security Technology Development  |  Avaya, Inc.
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Dan Wing
> Sent: Friday, August 26, 2005 8:05 PM
> To: 'Christian Stredicke'; 'Ignjatic, Dragan'; 'Lucas'
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Key Negotiation for SRTP
> 
> ...
> > So my bottom line of this discussion so far is (for someone 
> > who wants to implement this in a few MB):
> > 
> > 1. Implement SRTP
> > 
> > 2. Put the keys for SRTP in the SDP, probably with the 
> > a=crypto line(s)
> > 
> > 3. Use either TLS or S/MIME to make the key exchange secure/private.
> > 
> > Even if someone uses an insecure transport protocol for sending the
> > keys, that's a start. At least it does not reduce the 
> security level.
> > Hey lets think a little bit strategically here. Lure the 
> implementors
> > with SRTP and the crypto line, cuz that can be done 
> relatively easily.
> > Then step number three will come automatically later. 
> Jumping over the
> > mikey wall right from the beginning seems to be pretty hard 
> to me. And
> > in the end everybody has to implement TLS anyway.
> 
> I don't believe any standards organization would approve a
> recommendation
> for implementors to do (2) -- send encryption keys over an unencrypted
> channel.
> 
> > Having several conflicting proposals is not a good situation. 
> > It will help those people who want to see SIP dead.
> 
> I honestly don't know how to reduce this set of conflicting proposals:
> 
>   1. Security Descriptions (draft-ietf-mmusic-sdescriptions)
>   2. MIKEY with null encryptor (RFC3830)
>   3. MIKEY with pre-shared keys (RFC3830) 
>   4. MIKEY with RSA (public key) (RFC3830) 
>   5. MIKEY with DH (RFC3830)
>   6. MIKEY with DHHMAC (draft-ietf-msec-mikey-dhhmac)
>   7. MIKEY with ECIES (draft-ietf-msec-mikey-ecc)
>   8. MIKEY with ECMQV (draft-ietf-msec-mikey-ecc)
>   9. MIKEY with RSA-R (draft-ietf-msec-mikey-rsa-r)
> 
> -d
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 29 Aug 2005 14:19:28 -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.20050829140946.02a453a8 at qcmail1.qualcomm.com>
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> 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.
> 
> 
> >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?
> 
> 
> >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.
> 
> 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 24
> **************************************
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org