[VOIPSEC] Secure Real-time Transport Protocol (SRTP)

Thu Mar 24 20:41:39 CST 2005

I don't believe that initially this will be a drive; it is when real
tangible attacks become common that this may be a requirement. Personally I
would like to require it because the playing field is much larger in the IP
world. I think Skype proves that it can be done.

Christopher A. Martin
P.O. Box 1264
Cedar Hill, Texas 75106
Chris at InfraVAST.com

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Jeremy George
> Sent: Thursday, March 24, 2005 8:29 AM
> To: voipsec at voipsa.org
> Subject: Re: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> 
> 
>    Will HIPAA requirements drive encrypted voice/IM/video ?
> 
> - Jeremy
> 
> 
> On Wed, 23 Mar 2005, Brian Raymond wrote:
> 
> > Date: Wed, 23 Mar 2005 20:41:09 -0500
> > From: Brian Raymond <brian-lists at dataline.com>
> > To: kapnet at mindspring.com, VoIPsec <voipsec at voipsa.org>
> > Subject: Re: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >
> > I had a couple of comments for the thread.
> >
> > Avaya has always supported H.235 for security on H.323 calls so I would
> > imagine they are still doing the same now. I'm not sure however which
> > profile they are working with these days. There are a number of security
> > profiles (Annexes) specifying different algorithms for encryption and
> key
> > management. Related to MIKEY is H.235 Annex G, which is MIKEY and SRTP
> for
> > transport. Signaling of H.225 is generally encrypted via TLS or IPSEC,
> at
> > least what I've seen. Key exchange for media is over H.245 however the
> > method is specific to the profile.
> >
> > I agree with some of the other members that the main reason there isn't
> a
> > focus on application level security is that the market just hasn't
> demanded
> > it. That's starting to shift now but as someone who has previously
> worked
> > for a commercial vendor of a number of H.323/SIP products we never saw a
> > real demand from customers for that type of support. Any customers who
> > required security implemented it at layer 2/3 using some sort of VPN.
> This
> > was generally not an issue because that type of system was already in
> place
> > most of the time and provided much greater endpoint flexibility.
> >
> > I have supported the government sector for a few years now and even in
> what
> > are considered high(er) security environments with arguably critical
> data to
> > protect transport encryption was never a real issue. Again this is all
> > changing now and I'm seeing a number of splintered implementations
> popping
> > up. Most people I have talked to are only familiar with their specific
> > application's protocol implementation and when designing a solution
> aren't
> > concerned about interoperability. This is actually quite interesting
> because
> > these same applications are using standards to foster interoperability.
> >
> >
> > - Brian
> >
> >
> >
> > On 3/23/05 6:05 PM, "Ken Peterson" <kapnet at mindspring.com> wrote:
> >
> >> Ian,
> >>
> >> The only major vendor doing official SRTP, to my knowledge, is Cisco in
> >> release 4.1 of their CallManager, which was just released last fall.
> The
> >> signaling channel is protected via TLS - both phone and CM server have
> >> certificates to authenticate each other. Over this "always-up" control
> >> channel, they speak Cisco's proprietary Skinny protocol. During call
> setup,
> >> the CM sends a shared symmetric key to both IP endpoints. The endpoints
> >> then
> >> speak SRTP using AES-128 encryption and SHA-1 HMAC.
> >>
> >> I know of one major government organization that is implementing this
> >> solution as we speak. They are the rare exception, however.
> >>
> >> Avaya's solution is supposed perform a similar process, but using
> H.323.
> >> Their release date was pushed back last time I checked (was supposed to
> be
> >> out now.) Currently Avaya is using 102-bit AEA (Avaya Encryption
> Algorithm)
> >> between phones... I assume the voice is encapsulated in SRTP, but I
> could
> >> be
> >> wrong... anyone else know? The key exchange (again Im not confident in
> >> this,
> >> due to Avaya's lack of documentation) should be a Diffie-Helman
> exchange
> >> over the H.225 control channel. Is that D-H exchange authenticated to
> avoid
> >> MITM attacks? I would hope so, but I've seen no evidence to support
> that.
> >>
> >> Cheers,
> >>  Ken
> >>
> >>
> ************************************************************************
> >> *                             *
> >> *  Ken Peterson, CCIE 4297 *  Cisco Certified Security Professional
> >> *  PacketBrain, Inc.          *  Cisco IP Telephony Support Specialist
> >> *  Cary, NC 27511             *  Cisco Content Networking Specialist
> >> *                             *
> >>
> ************************************************************************
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]On
> >> Behalf Of Brian Rosen
> >> Sent: Wednesday, March 23, 2005 4:44 PM
> >> To: Ian.Cuthbertson at nokia.com; Voipsec at voipsa.org
> >> Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >>
> >>
> >> There is not much deployment yet.
> >> One of the reasons is confusion on key exchanges.
> >> Another is there is not (yet) much demand.
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]
> On
> >>> Behalf Of Ian.Cuthbertson at nokia.com
> >>> Sent: Wednesday, March 23, 2005 12:10 PM
> >>> To: Voipsec at voipsa.org
> >>> Subject: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >>>
> >>> Hi,
> >>>
> >>> Does anyone have a take on how widely deployed SRTP is in the real
> >>> world? Are all vendors offing solutions which include this (gateway,
> >>> handset etc)? Which key exchange methods do they support?
> >>>
> >>> Thanks, Ian
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >>
> >>
> >>
> >> _______________________________________________
> >> 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
> >
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org