[VOIPSEC] Voipsec Digest, Vol 15, Issue 39

Thu Mar 30 06:29:12 CST 2006

I think you can even look at lawful interception of encrypted voice
traffic, there are many companies that are working towards the same e.g
Verint Witness etc.

This is what would be required when people start adapting VOIP
encryption.

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Voipsec-request at voipsa.org
Sent: Thursday, March 30, 2006 4:30 PM
To: Voipsec at voipsa.org
Subject: Voipsec Digest, Vol 15, Issue 39

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. Sura ViDe/Net  - webcasts (Joao Pereira)
   2. Re: Using SRTP for University project (Hadriel Kaplan)
   3. 1. Help me for University Project (Deepak C Mathur)
      (Kolenko, Marc)

----------------------------------------------------------------------

Message: 1
Date: Wed, 29 Mar 2006 16:14:22 +0100
From: Joao Pereira <joao.pereira at fccn.pt>
Subject: [VOIPSEC] Sura ViDe/Net  - webcasts
To: Voipsec at voipsa.org
Message-ID: <442AA44E.6020702 at fccn.pt>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

In Vide.net will be a lot of discussing about security related topics,
take a look at the webcasts:

http://www.vide.net/conferences/spr2006/

Joao Pereira
FCCN

------------------------------

Message: 2
Date: Wed, 29 Mar 2006 12:16:27 -0500
From: "Hadriel Kaplan" <HKaplan at acmepacket.com>
Subject: Re: [VOIPSEC] Using SRTP for University project
To: "'Randell Jesup'" <rjesup at wgate.com>
Cc: Voipsec at voipsa.org, Christian.Stredicke at snom.de
Message-ID: <024601c65354$834bf7b0$6501a8c0 at acmepacket.com>
Content-Type: text/plain;	charset="us-ascii"

Hi Randell,
Sorry for not responding sooner - got sidetracked with my day job. 
Also sorry for this long email.
Comments inline...

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
On
> Behalf Of Randell Jesup
> Sent: Tuesday, March 28, 2006 12:48 AM
> To: Hadriel Kaplan
> Cc: Voipsec at voipsa.org; Christian.Stredicke at snom.de
> Subject: Re: [VOIPSEC] Using SRTP for University project
>
> There's trust, and then there's trust.  For example: I trust my phone
> provider to route my calls to my bank and not a scammer, but I don't
> trust them to stop a government agency from wiretapping me, even
without
> a warrant... 

If wiretapping is really your concern, then you shouldn't trust them,
because they will wiretap you - that's hardly a secret.  Well... the
general
fact is not a secret - the fact they're wiretapping you, Randell, is a
secret.  :)  (BTW, the problem I think you mean is that the warrant
isn't
legal - not that they don't have one - the lawful intercept systems I've
seen only operate with digitally signed warrants, though there's no
question
a human could be involved at an early step before it was signed, and
that is
a weak link)

But they will also intercept/tap your signaling, and for some warrants
(in
the US) that's all they legally can and will intercept.  That's a sign
to me
that signaling is sometimes as important as media.  :)  They will know
you
called the bank, and if you use sip Info for dtmf (vs. 2833) they will
know
the pin code you entered, too.  And if you called your mistress, they
will
know it.  And if you sent her an IM message saying "c u @home @1pm",
they
may send agents to watch you there. 

I'm not knowledgeable enough on lawful intercept legal issues to address
this topic; but if you make a call through a service provider covered
under
the US FCC mandate (which is basically all of them, and universities now
too
I think), they will comply with the ruling.  In fact, according to the
FBI,
a judge can order an enterprise to wiretap a call as well.  I've been
told
(by people who handle our lawful intercept support) that the service
providers have the legal responsibility of providing such, and that they
(the providers) feel it is required of them to not "support" calls which
cannot be legally tapped, whatever that means.  I've also been told by
someone else that if it's encrypted medium, then the provider does not
have
the legal responsibility to provide it in a decrypted form, and can
fulfill
the warrant by capturing the encrypted media.  This would be under the
notion of wiretapping only being required if technically feasible.  If
that's true, then zrtp may not be blocked (if it even could be, which is
debatable). 

But my guess is the providers would have figured out if that were not
true,
because it's quite expensive to actually build a network which can
wiretap
calls, and providers generally don't want to spend more than they have
to.
(and no we didn't drive them to this decision - SBCs were used long
before
wiretapping of voip became mandated by the FCC, and it's done by many
other
elements than SBCs as well)

But that's the US, and the idea is to make this a global thing, right?
Then
the issue gets very complicated. 

Again, the only way to assure it is not wiretapped for signaling or
media,
is to make a direct, encrypted and authenticated, sip-sip call and
bypass
the service provider proxies of all countries.  Nothing stops you from
doing
that today, as far as I know.  Or if media is your only concern, then
just
try zrtp or some other end2end media-level encrypt+auth every time and
if it
succeeds you succeed.

> And even here, while I trust them to not route me to a
> scammer on purpose, I might not trust their network security - they
might
> have been hacked and their servers compromised.  If the signalling is
> in-the-clear across (or in) ANY of their networks/servers, it's only
as
> secure as their entire network.  One keylogger/trojan/virus on the
wrong
> IT admin's machine, or 0-day MS exploit, and... poof.  When I call my
> bank's customer service, and have to give my account, SS#, password,
etc
> in order to talk to a human, that could all be tapped by a scammer.

The same could be said of the PC or voip phone from which you're making
the
call from or to, or the media gateway you're calling to reach the bank,
or
the PSTN switches, etc.  The only good news is the service providers
have a
lot at stake - if their equipment gets hijacked there is far more at
risk
than just your bank account # (unless you're Bill Gates).  So that is
the
implicit threat that will drive them to secure it.  But they have to
make a
profit, too, and if securing the solution makes it unreasonably
expensive,
my guess is the money side will win. 

> Or critical business negotiations might be tapped by a rival or
> competitor.

That can already happen in the PSTN and it doesn't seem to bother
enterprises at all.  In fact, some of them want to tap their own phones.
There are a few institutions which care, but they already do more today
to
secure it (and it costs them more).

> Media proxies
> (SBCs) want to modify SDP (IP's, ports, etc). 

Actually this is a common misconception, although I don't think you
meant
it.  But to be clear: SBCs don't want to do it - their owners want them
to
do it.  (Or most of them I should say - it's not true of all by any
means.)
But that's a very big difference.  All the SBCs I know of (including
ours)
do not have to modify or touch or look into SDP or RTP at all - that is
completely configurable.  Only non-ICE NAT traversal fixing needs that -
but
that's not the most common application for SBCs.  I think I've said
before
on this list that nat traversal is not even one of the top 3
features/reasons requested of an SBC. (though it may be #4 or 5)  An SBC
typically still provides a lot of value without touching SDP. 

Regardless of that ability to not touch SDP, most operators choose to
enable
it for numerous reasons, and when I say most I mean something like >80%.
At
least those I know of.  It's very possible this is a self-fulfilling
fact
for us because if you don't want SDP touched you probably don't think
you
need a hardware-based SBC (of course I think you'd be wrong, but that's
at
least debatable :).  But we also talk to service providers that don't
use
SBCs and the percentage holds.  This may change over time of course. 

BTW, SBCs are not the only "middle-elements" that touch SDP. (another
common
misconception, although again I don't think you meant it, but just to be
clear)

-hadriel

------------------------------

Message: 3
Date: Wed, 29 Mar 2006 12:03:44 -0500
From: "Kolenko, Marc" <Marc.Kolenko at gd-ais.com>
Subject: [VOIPSEC] 1. Help me for University Project (Deepak C Mathur)
To: <Voipsec at voipsa.org>
Message-ID:

<D0D936719BD98E40B8F2D8EAABB2A3E502EAD8CA at vach02-mail01.ad.gd-ais.com>
Content-Type: text/plain;	charset="us-ascii"

Research latest trends in deep-packet inspection via application-layer
firewalls for VoIP and telephony applications...that are the
best-in-breed vendors/technologies...best practices with regard to
configuration management consistent with layered security (i.e.,
defense-in-depth - IATF) approach....

____________________________________

Marc M. Kolenko, CISSP, NCTS
Lead Technologist
Information Assurance Advanced Technology
General Dynamics
Advanced Information Systems
Office:  703.383.3602     Cell:  703.298.4521

GDAIS Private Information

If you are not the addressee or authorized by the addressee to receive
this e-mail, you may not disclose, copy, distribute or use this e-mail.
If you have received this e-mail in error, please notify the sender
immediately by reply e-mail or by telephone at (703) 807-5672 and
destroy this message and any copies. Thank you

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Voipsec-request at voipsa.org
Sent: Wednesday, March 29, 2006 6:00 AM
To: Voipsec at voipsa.org
Subject: Voipsec Digest, Vol 15, Issue 38

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. Help me for University Project (Deepak C Mathur)
   2. Re: Help me for University Project (Joao Pereira)

----------------------------------------------------------------------

Message: 1
Date: 29 Mar 2006 10:16:17 -0000
From: "Deepak C Mathur" <deepak_neo at rediffmail.com>
Subject: [VOIPSEC] Help me for University Project
To: Voipsec at voipsa.org
Message-ID: <20060329101617.17245.qmail at webmail27.rediffmail.com>
Content-Type: text/plain;	charset=iso-8859-1

Hi all,
       I, Deepak Mathur, am currently pursuing MSc in Computer Networks.
I want to do a project in VoIP Security. Can you guyz suggest me some
topics for that. It will be a great help for me. Thank you all in
advance.
                         Deepak Mathur ?

------------------------------

Message: 2
Date: Wed, 29 Mar 2006 11:42:09 +0100
From: Joao Pereira <joao.pereira at fccn.pt>
Subject: Re: [VOIPSEC] Help me for University Project
To: Deepak C Mathur <deepak_neo at rediffmail.com>,  Voipsec at voipsa.org
Message-ID: <442A6481.5000908 at fccn.pt>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

You can try the OpenSER with TLS support, and check if it is a good
solution against SPIT and forged identities.
Joao

Deepak C Mathur wrote:

>Hi all,
>       I, Deepak Mathur, am currently pursuing MSc in Computer
Networks. I want to do a project in VoIP Security. Can you guyz suggest
me some topics for that. It will be a great help for me. Thank you all
in advance.
>                         Deepak Mathur 
>_______________________________________________
>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 15, Issue 38
***************************************

------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

End of Voipsec Digest, Vol 15, Issue 39
***************************************

DISCLAIMER:
This message contains privileged and confidential information and is intended only for the individual named. If you are
not the intended recipient you should not disseminate,distribute,store,print, copy or deliver this message. Please notify
the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.E-mail
transmission cannot be guaranteed to be secure or error-free as information could be intercepted,corrupted,lost,destroyed,
arrive late or incomplete or contain viruses. The sender therefore does not accept liability for any errors or omissions
in the contents of this message which arise as a result of e-mail transmission. If verification is required please request
a hard-copy version.