[VOIPSEC] Using SRTP for University Project

Wed Mar 22 00:29:37 CST 2006

I have managed to implement SRTP by a simple setup using two Snom 360  UAs and a CommuniGate Pro Server as the proxy and registrar in two PCs  inter-connected by a switch. I have also simulated packet sniffing  using Cain & Abel packet sniffer whereby I would only get static  noise in the captured media when SRTP is on. Are there any other  methods/applications that I could utilize to simulate other simple  security threats and prove SRTP's effectiveness?

  Regards,
  M Rizal B Azmi

Voipsec-request at voipsa.org wrote:  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: SRTP (Randell Jesup)
   2. Re: SRTP (Randell Jesup)
   3. Re: SRTP (Randell Jesup)
   4. Re: SRTP (Nathan Allen Stratton)
   5. Re: SRTP (Christian Stredicke)
   6. Re: SRTP (Jacqui Caren)

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

Message: 1
Date: Mon, 20 Mar 2006 14:40:42 -0500
From: Randell Jesup 
Subject: Re: [VOIPSEC] SRTP
To: "Dan Wing" 
Cc: 'Richard Polishak' ,
 Voipsec at voipsa.org
Message-ID: 
Content-Type: text/plain; charset=us-ascii

"Dan Wing"  writes:
>Cisco and Avaya have both been shipping SRTP for a year or two.
>And snom has SRTP.

The Woldgate Ojo (formerly distributed/labelled by Motorola) videophone
uses SRTP for video.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com

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

Message: 2
Date: Mon, 20 Mar 2006 16:26:08 -0500
From: Randell Jesup 
Subject: Re: [VOIPSEC] SRTP
To: Simon Horne 
Cc: Richard Polishak , Voipsec at voipsa.org,
 dan_york at Mitel.com
Message-ID: 
Content-Type: text/plain; charset=us-ascii

Simon Horne  writes:
>I have to totally agree, using a handset to me is much better then using 
>headphone/speakers (says the guy who writes softphones) but its true.

The same applies to webcams/chat vs standalone videophones (which is why
we're selling home H.264 videophones with LCDs).  Not to mention your
computer is likely not to be in the same sort of room where you like to
talk to people (kitchen, family room, perhaps bedroom, etc).

>The price of secure IP phones is most likely going to be quite high as 
>these devices would need quite a lot of expensive upgrades and include 
>things like encryption accelerator chips etc and they can be expensive. Are 
>people going to pay the money for them and is there a "big enough" market 
>for it?

SRTP doesn't need all that junk.  Even for videophones, we're not
encrypting a huge amount of traffic; a megabit or so at the outside (and
generally 384K or less - our videophone runs at 80-250K total including
audio and overhead at 30FPS).  For a DSP SRTP/AES is no challenge at all.
Or use a standard network processor with a built-in crypto engine as the
main controller CPU.  Might cost you $5 more than the chip without it -
maybe.  Added hardware cost (ignoring NRE) for encryption should be <$5,
and quite possibly $0.

>Then on the technical standpoint - there is no common standard way of doing 
>key exchange so it needs to support all or none. If the device talks to 
>another device that does not support the implemented method of encryption, 
>will the call fail? Can the call revert back to standard RTP?  These issues 
>and the "answer on zero ring" encrypted call problem are going to hamper 
>development of these devices.

These are the REAL issues.  We have a good standard for the streams (SRTP);
we have sucky (working) to non-existant standardization on the key exchange
and call-setup side.  Isn't that what we're in theory trying to deal with
here? 

>Another major issue for home office uses in the "Cool I have this secure
>IP phone now how the heck do I get it to traverse my NAT?" issue. Get an
>SBC!  :(

SRTP has no or little impact on NAT traversal.  So long as you don't 
encrypt the SIP traffic, in _theory_ key exchange doesn't mess up SBCs.
But that's edging into the vortex of problems with call setup.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com

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

Message: 3
Date: Mon, 20 Mar 2006 16:31:33 -0500
From: Randell Jesup 
Subject: Re: [VOIPSEC] SRTP
To: Nathan Allen Stratton 
Cc: Richard Polishak , Voipsec at voipsa.org,
 dan_york at Mitel.com
Message-ID: 
Content-Type: text/plain; charset=us-ascii

Nathan Allen Stratton  writes:
>There is MIKEY, but it is a bit overkill for most CPE vendors to
>implement. It looks like draft-ietf-mmusic-sdescriptions-12.txt is getting
>the most traction. I know of at least 4 CPE and 2 SBC that support it, I
>know there is at least one KIKEY CPE, but I don't know of any major SBC
>vendor that has implemented it.

The problem with sdescriptions is that it solves only one part of the
problem - how to put a key in SDP.  It doesn't provide the AKE to secure
the key exchange.  So sdescription support is NOT sufficient, and honestly
while useful it's not the hard part.  Then there's early media, forking,
grouping of secure vs. insecure streams, etc.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup at wgate.com

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

Message: 4
Date: Mon, 20 Mar 2006 18:36:30 -0500 (EST)
From: Nathan Allen Stratton 
Subject: Re: [VOIPSEC] SRTP
To: Randell Jesup 
Cc: Richard Polishak , Voipsec at voipsa.org,
 dan_york at Mitel.com
Message-ID: 

Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 20 Mar 2006, Randell Jesup wrote:

> Nathan Allen Stratton  writes:
> >There is MIKEY, but it is a bit overkill for most CPE vendors to
> >implement. It looks like draft-ietf-mmusic-sdescriptions-12.txt is getting
> >the most traction. I know of at least 4 CPE and 2 SBC that support it, I
> >know there is at least one KIKEY CPE, but I don't know of any major SBC
> >vendor that has implemented it.
>
> The problem with sdescriptions is that it solves only one part of the
> problem - how to put a key in SDP.  It doesn't provide the AKE to secure
> the key exchange.  So sdescription support is NOT sufficient, and honestly
> while useful it's not the hard part.  Then there's early media, forking,
> grouping of secure vs. insecure streams, etc.

That is why you use TLS, most SBCs can support tens of thousands of TLS
sessions now.

-Nathan

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

Message: 5
Date: Tue, 21 Mar 2006 02:14:29 +0100
From: "Christian Stredicke" 
Subject: Re: [VOIPSEC] SRTP
To: "Randell Jesup" , "Simon Horne"

Cc: Richard Polishak , Voipsec at voipsa.org,
 dan_york at Mitel.com
Message-ID:

Content-Type: text/plain; charset="us-ascii"

As a phone vendor I can say that SRTP is relatively cheap - you dont see
it on the CPU load. However, the key negotiation requires a lot of
number crunching, which may block the CPU for a few feconds. IMHO this
is not acceptable when you pick up a phone call, therefore we decided to
go with sdes.

Hardware accelerators are pretty useless here. If you have a problem
with several megabits for video, your CPU must be able to deal with this
heavy load anyway and the SRTP piece does not make a difference any
more.

Security does *not* increase the price of a device. The extra memory
that you need is neglectable.

Christian

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org 
> [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Randell Jesup
> Sent: Monday, March 20, 2006 3:47 PM
> To: Simon Horne
> Cc: Richard Polishak; Voipsec at voipsa.org; dan_york at Mitel.com
> Subject: Re: [VOIPSEC] SRTP
> 
> Simon Horne  writes:
> >I have to totally agree, using a handset to me is much better then 
> >using headphone/speakers (says the guy who writes 
> softphones) but its true.
> 
> The same applies to webcams/chat vs standalone videophones 
> (which is why we're selling home H.264 videophones with 
> LCDs).  Not to mention your computer is likely not to be in 
> the same sort of room where you like to talk to people 
> (kitchen, family room, perhaps bedroom, etc).
> 
> >The price of secure IP phones is most likely going to be 
> quite high as 
> >these devices would need quite a lot of expensive upgrades 
> and include 
> >things like encryption accelerator chips etc and they can be 
> expensive. 
> >Are people going to pay the money for them and is there a 
> "big enough" 
> >market for it?
> 
> SRTP doesn't need all that junk.  Even for videophones, we're 
> not encrypting a huge amount of traffic; a megabit or so at 
> the outside (and generally 384K or less - our videophone runs 
> at 80-250K total including audio and overhead at 30FPS).  For 
> a DSP SRTP/AES is no challenge at all.
> Or use a standard network processor with a built-in crypto 
> engine as the main controller CPU.  Might cost you $5 more 
> than the chip without it - maybe.  Added hardware cost 
> (ignoring NRE) for encryption should be <$5, and quite possibly $0.
> 
> >Then on the technical standpoint - there is no common 
> standard way of 
> >doing key exchange so it needs to support all or none. If the device 
> >talks to another device that does not support the 
> implemented method of 
> >encryption, will the call fail? Can the call revert back to standard 
> >RTP?  These issues and the "answer on zero ring" encrypted 
> call problem 
> >are going to hamper development of these devices.
> 
> These are the REAL issues.  We have a good standard for the 
> streams (SRTP); we have sucky (working) to non-existant 
> standardization on the key exchange and call-setup side.  
> Isn't that what we're in theory trying to deal with here? 
> 
> >Another major issue for home office uses in the "Cool I have this 
> >secure IP phone now how the heck do I get it to traverse my NAT?" 
> >issue. Get an SBC!  :(
> 
> SRTP has no or little impact on NAT traversal.  So long as 
> you don't encrypt the SIP traffic, in _theory_ key exchange 
> doesn't mess up SBCs.
> But that's edging into the vortex of problems with call setup.
> 
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), 
> ex-Amiga OS team rjesup at wgate.com
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> 
> 

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

Message: 6
Date: Tue, 21 Mar 2006 10:00:46 +0000
From: Jacqui Caren 
Subject: Re: [VOIPSEC] SRTP
To: Voipsec at voipsa.org
Message-ID: <441FCECE.3000209 at ntlworld.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Christian Stredicke wrote:
> Security does *not* increase the price of a device. The extra memory
> that you need is neglectable.

Another issue is battery life.

In a recent article elsewhere comparisons of battery life between music
players using DRM'd and non drm'd playlists showed that battery life is
almost halved. Public feedback seems to be that this is far too much of
a "cost" - they do not care about DRM - but they care about losing 2 
hours of play time :-)

Of course, people who buy secure phones want them, people who buy DRM'd
players don't (care).

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

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

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

---------------------------------
 Yahoo! Mail
 Use Photomail to share photos without annoying attachments.