[VOIPSEC] VOIP Security in its Totality

[Paine, Richard H]

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