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

Paine, Richard H richard.h.paine at boeing.com
Mon Mar 28 08:03:28 CST 2005 

The Open Group's Secure Mobile Architecture (SMA) assigns a
cryptographic identity to every packet
(http://www.opengroup.org/bookstore/catalog/e041.htm).  This means that
VOIP calls are secure end to end and a policy can be applied to location
and authorized participants.  There are four elements to the SMA; a PKI,
the Host Identity Protocol (HIP), a Network Directory Service (NDS), and
a Location Enabled Network Service (LENS).  No more SPAM or spoofing
because the Security Association guarantees identity.

Such an architected system can meet the HIPAA requirements.

Richard H. Paine
Success is getting what you want, happiness is liking what you get!
Cell:  206-854-8199
IPPhone:  425-373-8964
Email:  richard.h.paine at boeing.com 


-----Original Message-----
From: Mark Teicher [mailto:mht3 at earthlink.net] 
Sent: Sunday, March 27, 2005 2:51 PM
To: voipsec at voipsa.org
Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)

Based on what has been stated regarding VOIP security, one could
hypothetically utilize
http://a257.g.akamaitech.net/7/257/2422/14mar20010800/edocket.access.gpo
.gov/2003/03-3876.htm
in regards Electronic Data Interchange, depending on the content of the
information that is transmitted over a VOIP infrastructure (i.e. patient
name, patient information, etc).
In most cases, as originally stated neither GLBA and HIPAA call out
enforcement within a communications infrastructure.  It is very hard for
organizations who provide VOIP infrastructure equipment to provide that
type of assurance to enterprises they provide to.  Currently there are
very few organizations who will certify a VOIP infrastructure for
security compliance let alone GLBA and HIPAA.  Even if such assurances
were provided, an organization providing this type of assurance would be
liable if any part of the VOIP infrastructure were to fall out of
compliance for any reason or be compromised by a untrusted party.
Indemnification policies currently supported by such VOIP managed
service providers would definitely need to be re-evaluated in the near
future.



At 05:42 PM 3/25/2005, Zmolek, Andrew \(Andy\) wrote:
>Neither GLBA nor HIPAA specifically call out communications 
>infrastructure. However, since there is no specific exclusion for it, 
>the issue cannot simply be dismissed.
>
>For HIPAA the basic test is whether "Protected Healthcare Information"
>is stored electronically in a given system. In the case of a VoIP call 
>that will only be true if the call is recorded and stored. So voicemail

>and call recording systems may need to document HIPAA conformance if 
>healthcare information is likely to be discussed. And any call center 
>systems that access healthcare records will need similar documentation.
>
>It should be pointed out that there is no requirement (even indirectly)

>for encryption of signaling or media by HIPAA regulations. In fact no 
>specific mention of voice systems in general (much less VoIP) can be 
>found in the privacy and security regulations, which can be found here:
>http://aspe.hhs.gov/admnsimp/index.shtml
>
>GLBA is similar in that it has a "safeguarding" component distinct from

>the privacy component we all know about from the disclosures one 
>routinely receives in the mail. A couple of years ago, the FFIEC 
>finally came out with detailed guidance to bank regulators (you can 
>find their examination guidelines at 
>www.ffiec.gov/ffiecinfobase/html_pages/it_01.html but you won't see 
>VoIP specifically mentioned). It can easily be argued that the risk 
>management program detailed by the FFIEC should apply to VoIP systems 
>just as any other application on the data network. We certainly have 
>customers in the financial sector who believe so and act accordingly, 
>although I've seen a much greater focus from those customers on 
>auditability than on encryption.
>
>When it comes to enforcement, GLBA does have a meaningful regulatory 
>surround with regular inspections by regulators who can inflict 
>considerable pain on a non-conforming institution. The same cannot be 
>said of HIPAA which is ultimately overseen by the Office of Civil 
>Rights, who does not perform regular inspections and has only 
>threatened action in a handful of egregious cases.
>
>
>/\\//\Y/\   Andy Zmolek
>             GCS Security Team
>             zmolek at avaya.com
>             303-538-6040
>
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On

>Behalf Of Mark Teicher
>Sent: Friday, March 25, 2005 11:50 AM
>To: Bonnell, Joseph D (Joe); Chris at sip1.com; kapnet at mindspring.com; 
>Jeremy George
>Cc: Voipsec at Voipsa. Org
>Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
>
>J,
>
>Could you provide the sections in GLB and HIPAA where communications
>infrastructure(s) is impacted?? For some reason I cannot recall those 
>individuals sections..
>
>/m
>
>-----Original Message-----
>From: "Bonnell, Joseph D (Joe)" <jobo at avaya.com>
>Sent: Mar 25, 2005 11:51 AM
>To: Chris at sip1.com, kapnet at mindspring.com,
>         Jeremy George <jeremy.george at yale.edu>
>Cc: "Voipsec at Voipsa. Org" <voipsec at voipsa.org>
>Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
>
>Agreed.
>
>Both GLB and HIPAA have enormous impact within the communications 
>infrastructure (irrespective of whether it's a VoIP deployment or not).
>
>Unfortunately for most, SOX seems to be getting all the attention so 
>these other legislative directives seem to be lost in the fodder.
>
>Regards,
>
>J
>
>Joe Bonnell CISSP NSA-IAM| Manager, Communications System Security 
>Services | Avaya Global Services |720.444.4410| jobo at avaya.com | 
>www.avaya.com/security
>
>-----Original Message-----
>From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On

>Behalf Of Christopher A. Martin
>Sent: Thursday, March 24, 2005 7:37 PM
>To: kapnet at mindspring.com; 'Jeremy George'
>Cc: 'Voipsec at Voipsa. Org'
>Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
>
>I believe, if it is considered data, which VoIP is, it falls under the 
>same rules. Then again, those enforcing the regulations barely 
>understand the requirements themselves and probably wouldn't even think

>about VoIP.
>
>But that may be a large assumption on my part (but I have seen this 
>from some of the auditors that I have run into).
>
>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 Ken Peterson
> > Sent: Thursday, March 24, 2005 10:50 AM
> > To: Jeremy George
> > Cc: Voipsec at Voipsa. Org
> > Subject: RE: [VOIPSEC] Secure Real-time Transport Protocol (SRTP)
> >
> > Jeremy,
> >
> > Last time I checked, HIPAA doesnt require any kind of voice
>transmission
> > to
> > be secured... including VoIP.
> >
> >               Cheers,
> >                  Ken
> >
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org 
> > [mailto:Voipsec-bounces at voipsa.org]On
> > Behalf Of Jeremy George
> > Sent: Thursday, March 24, 2005 9: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
> >
> >
> >
> > _______________________________________________
> > 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

More information about the Voipsec mailing list