[VOIPSEC] Mulig_SPAM: VOIP Security in its Totality

Wed Mar 8 13:17:23 CST 2006

Dear Richard,

Your argumentation is 100% correct in my opinion. I am currently working on 
a concept fore secure environment communications in closed MPLS networks. 
The basic understanding of the Internet's fundamental "flaws" in regards to 
security is the driving factor fore the IP-Matrix concept.

The Open Group report will surly be of great help to the projects further 
development. Also I would like to applaud VOIPSA fore the Threat Taxonomy - 
witch also has proofed to be weary useful.

My question (anyone):

Are the IP Multimedia Subsystem (IMS) and the Secure Mobile Architecture 
(SMA), to unrelated concepts/architectures that deal with the same issues?

I need to understand the potential similarity's between the two from a 
philosophical perspective?

If anyone can advise I would be most grateful.

Regards, Patrick W. Ireland

Patrick at Voiceline.dk

----- Original Message ----- 
From: "Paine, Richard H" <richard.h.paine at boeing.com>
To: <Voipsec at voipsa.org>
Sent: Tuesday, March 07, 2006 7:17 PM
Subject: Mulig_SPAM: [VOIPSEC] VOIP Security in its Totality

> VOIP Security in its Totality
>
> I have been on this mailing list from the start and I have seen all of
> your variants that you think might make VOIP secure.  Some of you will
> leap on a proposed solution and ride it for awhile, but then you realize
> all the issues and problems that come with implementing pieces and not
> the whole.
>
> There are some fundamental problems that you are still not addressing.
> The biggest problem is that the Internet has some fatal flaws.  Those
> flaws are the vulnerability of the basic Internet to spoofing of MAC and
> IP addresses.  Other flaws include the inability of IPv4 and IPv6
> gateways to scale to the size of the Internet.  You are not going to get
> around those using a VPN solution.
>
> There have to be some fundamental changes in the way the Internet
> operates.  One way is through a framework and architecture called the
> Secure Mobile Architecture (SMA).  This architecture is published by The
> Open Group and is available at the following URL:
> http://www.opengroup.org/bookstore/catalog/select.tpl?text=secure+mobile
> +arch The architecture addresses many of the issues you have been
> talking about.  Until we actually address the issues of basing security
> on the MAC and IP addresses, all of your approaches will not address the
> basic problem.
>
> I have an example of the issues hiding our heads in the sand can lead
> to.  I have been a member of IEEE 802.11 since about 1995.  Boeing got
> involved in 802.11 because of the potential solutions 802.11 provided
> for both Internet access onboard airplanes and for the mobile enterprise
> communications.  So I got involved early in the security provided for
> the Wireless LANs.  The initial group of 802.11 standards developers
> felt, as I did, that the WEP was sufficient (good enough) to get the
> standard rolling.  It wasn't!  The work around was VPNs for any wireless
> connections, but it definitely slowed and inhibited the growth of WLANs.
> It took six years to provide a WEP replacement that was
> cryptographically secure.
>
> If IEEE 802.11i is any example, the VOIP growth and viability is
> inexorably tied to how secure our telephone calls are.  I have always
> been incredulous that we never cared very much how vulnerable our
> telephone conversations are.  The wire makes us seem less vulnerable,
> but in fact, backbone communications links are sometimes over major
> microwave links.  Many of the Fortune 500 contractually stipulate that
> none of their business communications are sent over microwave links.
> In addition to the microwave links, we have wholly trusted our telephony
> companies to protect us and they have done quite a good job in that most
> of the connections are in central offices that have not been broken
> into.  This is all changing now and this mailing list is at the
> forefront of the discussion.  What do we do about voice security now
> that our telephone conversations are riding over the Internet and have
> all the Internet vulnerabilities of viruses, MAC address spoofing, IP
> address spoofing, replay, spamming, etc?
>
> In the big picture, end-to-end secure sessions with cryptographically
> based mechanisms to identify people and machines are the only way to
> assure secure VOIP communications.  In our work with the Secure Mobile
> Architecture (SMA), we have been exposed to all the regulatory
> requirements for privacy and legality.  These requirements include
> Sorbannes-Oxley, HIPPA, and many others.  They are quite extensive and
> demanding, especially of privacy and protection from exposure on the
> Internet.  Without addressing the requirement of an end-to-end
> cryptographically secure infrastructure, we are not addressing the
> problem and those of us responsible for unleashing VOIP on the world
> have a responsibility to address this problem in a big picture way.
>
> The core of the problem comes from the relationship of security and
> identity.  When I first heard and participated in discussions on
> identity management, I was very skeptical that this was a required
> discipline at all.  In fact, I still think that identity management is
> not the right term for what we need to address in Internet VOIP and WLAN
> infrastructure contexts.  We do not need to manage the identities.  In
> reality, the people, organizations, and enterprises need to be assured
> that their identities are protected when they use the Internet.  So, the
> identity of a person or machine must be protected in a business context
> or in an individual context.  By the way, this identity of a machine is
> an imperative one to address.  We are still not doing a good job of
> identifying a computer or intelligent machine's identity.   In fact, as
> VOIP gets more integrated into the business processes and telephony
> becomes more versatile and VOIP applications are used for event
> notification, the validity of such processes is dependent on getting the
> cryptographically validated sources of the VOIP information you get.
>
> The architecture The Open Group developed called the Secure Mobile
> Architecture (SMA) deals with these issues through the use of four
> elements (Boeing deployment);  1. Public Key Infrastructure (PKI)
> access, 2. use of the Host Identity Protocol (HIP), 3. a Network
> Directory Service (NDS), and 4. use of a Location Enabled Network
> Service (LENS).  I will treat each of these and their relationship to
> VOIP and VOIP security in the following four paragraphs.
>
> PKI:  The access to a PKI is needed for managing the issuance and
> revocation of certificates for identity.  Boeing has an enterprise PKI,
> the US government has multiple PKIs, and many business entities have
> PKIs.  The PKI functionality actually is moving down the scale from
> large scale enterprises mechanisms to smaller and smaller scale
> organizations, and I suspect that it will eventually get down to the
> individual machine level that PKIs will be managed on individual
> machines.  The certification authority will be offered by large scale
> third party companies that do background checks and validate the
> individuals and machines, that is, if these certification authorities
> are not in large enterprises.  What applicability does this have to the
> VOIP security arena?  This element of the SMA is the way to provide a
> certification authority to validate the end user or device is who or
> what it says it is.  So, when you get a VOIP call, you can be assured
> that the person or machine who is contacting you is who they say it is.
> The same applies when you are making a call.  You can be assured that
> when you are calling who you meant to call and they are who they say
> they are.
>
> HIP:  The use of the Host Identity Protocol (HIP) puts a cryptographic
> identity on every packet.  The packets look just like IPSEC packets, so
> they are routable anywhere in the world.  In addition, HIP uses a
> namespace rather than an address space and creates a Security
> Association (SA) between the end-to-end communicators.  Because the
> Security Association is established and depends on a namespace, the IP
> addresses can change and the Security Association remains and can enable
> the devices to roam across IP subnets or diverse networks such as
> cellular to WLAN.  The cryptographic identity is a derivative of a hash
> of the certificate and is put in the ESP field and is an SPI in the
> IPSEC-like packet.  The HIP has several versions and implementations.
> The Boeing SMA implementation uses a virtual directory to store
> information of the initiator/responder.  Other implementations use the
> DNS resource record to store the namespace information to navigate
> through the namespace.  The implementation of this in the VOIP security
> context would be the VOIP service providers providing the HIP
> infrastructure to their customers to enable security and mobility for
> them.
>
> NDS:  The Network Directory Service provides the data store for the
> information required to maintain both the network and OS information
> needed to allow secure mobility.  The directory must be a virtual
> directory from which the information can be stored in an enterprise or
> ISP business directory.  Since it is a virtual directory, the
> information could be stored in a database or flash memory card or
> whatever is deemed necessary to provide the needed information to the
> initiator and responder of the Security Association pair.  The virtual
> directory provides the storage for the IP address, the location, and
> policy information to make decisions about the communications and
> mobility.  The enterprise or ISP directory can be one arm of the virtual
> directory, so the people and server information of the existing
> directories can be available to the SMA information stores.  In the VOIP
> security context, the VOIP ISP provides secure mobile communications
> from end-to-end for each call.  This means secure both over the wire and
> the wireless and it is always encrypted and cryptographically
> identified.
>
> LENS:  The Location Enabled Network Service (LENS) is a Real-Time
> Location Service (RTLS) that provides location information about the
> communications pairs.  The location service enables an enterprise to
> know not only who the participants are, but also knows where they are
> for emergency services or business process flow optimization.  The SMA
> uses the LENS for policy-enforcement of location and identity.  For
> example, US government providers must provide differentiation between US
> citizens and non-US citizens and enable restrictions on what government
> information may be disclosed in what geographical areas.  The location
> provided by the LENS can be the key to customer managing their employees
> in restricted areas.  Location events may be triggered when a non-US
> citizen enters an area restricted to US citizen only.  Also, emergency
> location information for health emergencies (such as E911) is a
> difficult requirement for most US ISPs and enterprises.  The location
> provided by the network is really the only way to get location
> information indoors within the US government requirement of 300ft.  IEEE
> 802.11 location services are generally the source of indoor location and
> the cellular and GPS location services are the source of information
> outdoors.
>
> These four elements (PKI, HIP, NDS, and LENS) make up the core of an SMA
> secure and mobile VOIP telephony environment.  Trying to do a piecemeal
> TLS or SSL or PGP solution is only addressing a small part of the
> overall problem of securely enabling mobile VOIP communications.  In our
> opinion, only by addressing this problem on a framework or architectural
> basis, like SMA, are you able to address the underlying VOIP security
> issues of supporting security and mobility as an enterprise or as an
> ISP.  The interesting thing about this architecture is that it can be
> provided piecemeal as a service.  You can start out with supporting
> requirements for a secure and mobile service within your Intranet to
> support those who have the requirement.  The SMA capability can be
> implemented on your Intranet and serve as your IT support for projects
> that require security and mobility on your existing WLAN and wired LAN
> infrastructure.  Since it looks like IPSEC, an SMA subscriber using the
> WLAN and wired LAN infrastructure for transport and the
> cryptographically identified packets enable traceability across your
> enterprise or ISP constituency.  Without such a framework or
> architectural approach, security and mobility will continue to be
> plagued with inconsistency and partial solutions that do not address the
> issues.
>
> We have deployed SMA nodes in three physical and logical installations
> in The Boeing Company.  We could have gotten by with only one, but
> another installation was needed to investigate issues with directory
> replication and distribution and the third is being installed in a lab
> environment to support a laboratory and simulation network.  We have
> deployed the infrastructure as a mobile rack that is a self contained
> node that can be deployed in a Network Control Center.
>
> In conclusion, addressing VOIP security in its totality is an
> imperative, especially in organizations with military, HIPPA,
> industrial, and government requirements.  What I recommend to this
> mailing list is to consider at least one of VOIPSA solutions to be an
> architected infrastructure implementation that addresses the totality of
> the Internet and its present deficiencies.  SMA is an example of such an
> architected infrastructure implementation and I hope to present the SMA
> to the VOIPSA at some point.
>
> 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
>
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 