[VOIPSEC] Voipsec Digest, Vol 8, Issue 24

Chorley, Will Will_Chorley at labs.sbc.com
Wed Aug 31 08:45:48 PDT 2005


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

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




More information about the Voipsec mailing list