[VOIPSEC] (no subject)

Thu Mar 9 08:11:22 CST 2006

unsubscribe

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org]On
Behalf Of Voipsec-request at voipsa.org
Sent: 09 March 2006 12:00
To: Voipsec at voipsa.org
Subject: Voipsec Digest, Vol 15, Issue 7

Send Voipsec mailing list submissions to
	Voipsec at voipsa.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
or, via email, send a message with subject or body 'help' to
	Voipsec-request at voipsa.org

You can reach the person managing the list at
	Voipsec-owner at voipsa.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Voipsec digest..."

Today's Topics:

   1. Re: VoIP Security Assessment Tools (mohamed)
   2. Re: Mulig_SPAM:  VOIP Security in its Totality (Voiceline)

----------------------------------------------------------------------

Message: 1
Date: Wed, 08 Mar 2006 18:21:21 +0100
From: mohamed <Mohamed.Nassar at loria.fr>
Subject: Re: [VOIPSEC] VoIP Security Assessment Tools
To: "Shawn Merdinger" <shawnmer at gmail.com>, Voipsec at voipsa.org
Message-ID: <440F1291.2080809 at loria.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi all,
Thanks Shawn for your list. It will be of great usefulness for me in my 
phd thesis on VoIP security. 
But if you or somebody can complete this list with some H.323 suit 
protocols specific tools.
Thanks.

------------------------------

Message: 2
Date: Wed, 8 Mar 2006 20:17:23 +0100
From: "Voiceline" <Patrick at Voiceline.dk>
Subject: Re: [VOIPSEC] Mulig_SPAM:  VOIP Security in its Totality
To: "Paine, Richard H" <richard.h.paine at boeing.com>,
	<Voipsec at voipsa.org>
Message-ID: <008701c642e4$ee0d3ee0$0b01a8c0 at patrick>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original

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
> 

------------------------------

_______________________________________________
Voipsec mailing list
Voipsec at voipsa.org
http://voipsa.org/mailman/listinfo/voipsec_voipsa.org

End of Voipsec Digest, Vol 15, Issue 7
**************************************