SMA, VoIP and Identity

There was an interesting description on SMA (Secure Mobile Architecture) by another Richard from Boeing🙂. SMA is expected to address security issues in VoIP and identity for those enterprise networks with some sample implementation inside Boeing


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@boeing.com

Comments are closed.

%d bloggers like this: