Here is another paper for the University of Dallas
Abstract
Business to Business (B2B) web portals have become very common in current corporate environments where companies deal with partners, clients, resellers, vendors, vendees, licensees, outsourcers along with anyone they do business with in an ongoing basis. These portals are available for connectivity through the Internet but the access levels are often restricted by access controls based on authenticating a user account connecting to the site. As these portals have evolved, more than just web content is becoming available to the user of the B2B sites. Access controls are becoming more complex and more customizable data is created for specific use based upon confidentiality and integrity. Secure Socket Layer Virtual Private Network (SSL VPN) solutions are trending to the future of connectivity for a variety of users that can transfer data via a secure connection that is initiated over a web portal interface through an encrypted connection across the Internet.
This paper discusses the topic of implementing a B2B portal using a SSL VPN solution for the purpose of establishing secure interface where transfer of business data is exchanged. Concepts that are covered are network architecture, Public Key Infrastructure (PKI), access control list (ACL), end-point detection and popular vendor implementation. Securing electronic commerce via a SSL VPN web portal to an extranet provides the flexibility to communicate via a variety of devices from web enabled phones, Personal Digital Assistants (PDA), kiosk system, Net Books, PC’s and laptops regardless of operating system or browser used. This extensible solution is enabling the further collaboration amongst business around the globe.
Introduction
Businesses, both large and small, have a need to share information. Companies have used messengers to courier data between itself to partners and customers. With the advent of computing, electronic data interchange (EDI) technology quickly took shape. To provide value on how a SSL VPN solution to connect to a B2B portal, a historical perspective on Extranets and VPNs is necessary. The SSL VPN will establish the solution that is the cost effective and extensible to server the greatest variety of end user systems that connect to the B2B portal.
Extranets
“Extranets have been around since the first rudimentary LAN-to-LAN networks which began connecting two different business entities to form WANs.” (Maier, 2000) An Extranet is usually a perimeter network placed on the Internet so that data can be accessed from external business partners. The term Extranet is very broad in nature. “Similar to most emerging technologies, "extranet" does not have a clear definition, either in the academic world or in practice. Yet many people try to give it a descriptive explanation.” (Ling & Yen, 2001) The B2B portal is the entry point for business to share data between entities. Portals have ranged from dial-up Bulletin Board Systems to more sophisticated firewall protected perimeter networks, sometimes referred to as a Demilitarized Zone (DMZ). Extranets have been used for many types of collaboration, Electronic Data Interchange (EDI), Supply Chain Management (SCM), Enterprise Resource Planning (ERP), Customer Resource Management (CRM), Software as a Service (SaaS), and Application Service Providers (ASP) which are just some of the many examples.
Historically, the portal for an Extranet has been a firewall. Access given to the extranet is an open pass-through for certain protocols to specified servers and even to the point where it could be allowed from only a certain IP address or network range. In this example, we see that there is not a separate network segment for the Extranet and the Intranet. This is a simple solution that does not cost very much to implement based on configuration and hardware. Maintenance is very simplified and cost effective too. The data is easily accessible from internal clients as well. The risk is that there is just a single firewall that divides the Intranet/Extranet from the Internet. The below figure is an example of the topology for this.
A single layer extranet solution as shown in Figure 1 is not the most secure solution available. Security considerations have been the impetus to the concept of the perimeter network known as a DMZ. This design architecture has become widely adopted by many enterprises that have implemented a sophisticated Internet presence that has web, B2B, B2C and other connected applications (eg. E-mail). This topology implementation restricts external user access to only the perimeter network. Content can be isolated to a server farm in the perimeter network which leads to simplified sharing and maintenance across the intranet and extranet. An argument could be made that content is safer on the perimeter network due to the isolation of the data. A virus outbreak in on the intranet on the client workstations is less likely to spread to the perimeter network and an attack from the internet is likely to be isolated to systems located only on the perimeter network. User accounts for external users could be segregated from internal user accounts in the corporate networks when using a separate domain (Windows Active Directory) or realm (Unix NIS). More advanced implementations utilize reverse proxy web publishing as opposed to port forwarding. There are some disadvantages to consider in this deployment over the simplified network. Additional hardware is needed for the additional network segments and firewalls. There is a greater overhead for maintenance of user accounts and access rules. In the below Figure 2, this illustrates how a multi-layer perimeter network might appear. This architecture could transform into more complex scenarios by adding more layers of firewalls subnets ad infinitum.
VPN
VPN is the acronym for Virtual Private Network. In a nutshell, a VPN is when one protocol is wrapped within a TCP protocol packet and this packet is sent across a public network to a network that is considered private where the payload is unwrapped and then sent to its destination. The client establishes a virtual tunnel to the VPN server. A variation is the site-to-site VPN tunnel that connects two private networks between two VPN servers. This is in actuality two one way client server connections. Client authentication is usually done via the SLIP (Romkey, 1988)or PPP (Simpson, 1994) authentication methods. In May 1998, Cisco Systems introduced the L2F protocol with RFC 2341 (Kolar, Littlewood, & Valencia, 1998). This was one of the first commercially successful implementations of the VPN concept. In July 1999, Microsoft introduced the PPTP Protocol with RFC 2637 (Zorn, Taarud, Little, Verthein, Pall, & Hamzeh, 1999). PPTP allowed any Windows 95 client or higher to connect to a Windows NT 4 SP 3 or higher server running Routing and Remote Access. Cisco and Microsoft then combined efforts to engineer to L2TP protocol in RFC 2661 (Pall, Palter, Rubens, Townsley, Valencia, & Zorn, 1999). This collaboration combined the ability to do encapsulation with encryption using Kerberos, Certificate (PKI) or pre-shared secret. On the open source front, IPSec transport and tunnel modes based on RFC 2401 (Kent & Atkinson, 1998). Microsoft, Cisco and other networking device manufactures quickly adopted the IPSec standards for interoperability purposes. The main disadvantages of these VPN solutions are that it requires a piece of software on the client for L2F, PPTP and L2TP, and policy configurations for IPSec that can be very complex. While IPSec VPN solutions are seemingly operating system agnostic, there tends to be several interoperability issues between systems. The PPTP and L2TP solutions do require custom software installations for PPTP and L2TP on non-Windows systems and the L2F solution requires proprietary Cisco VPN client software. Due to these limitations, the quest was on to go to a VPN solution that could work from any device regardless of operating system.
SSL VPN
Secure Sockets Layer VPN (SSL VPN) is the solution for connecting to remote networks using trusted and encrypted connectivity without using any preinstalled client software, using dial up networking or configuring policies for IPSec. SSL VPN is able to establish a connection using a standard web browser, such as Microsoft Internet Explorer or Mozilla Firefox. To establish the SSL VPN connection, a user simply has to visit a web page using the HTTPS protocol. The web browser will then download an ActiveX or Java component is downloaded to the system which then wraps the TCP/IP network traffic destined to the remote network. As the traffic traverses the public networks in the SSL VPN, the protocol being used is Transport Layer Security (TLS) first described in RFC 2246 (Allen & Dierks, 1999) and later updated in RFC 5246 (Dierks & Rescorla, 2008). The TLS protocol has been used to secure HTTP, FTP, SMTP and many other protocols used across the web.
The TLS protocol secures the information by encrypting the data payload using Public Key Infrastructure (PKI) methods. In brief, PKI is the usage of certificates to cryptographically encrypt data which insure that the exchange between two parties is secure based upon a third party certificate authority. The information is encrypted after the public key is sent from party #1 to party #2 where the party #2 encrypts the data using the public key from party #1 whereupon party #1 decrypts the information using part #1’s private key. This was a very brief description of the Diffe-Hellman Key exchange (Rescorla, 1999).
SSL VPN solutions can offer additional security features such as the use of Extensible Authentication Protocol (EAP) (Aboda, Simon, & Eronen, 2008). EAP usage normally includes the use of a smart card. This two factor authentication demonstrates that to authorize access to the SSL VPN requires that the user can be identified by something the user has in possession and something the user knows. Another security feature is that the Java or ActiveX client software has the option to do endpoint detection. Endpoint detection can check the client system for minimum requirements for security, such as the presence of anti-virus software, virus signature updates, and security patch levels along with many other configuration settings. Using the endpoint detection functionality helps boost confidence levels for network administrators allowing remote systems connecting to the internal network. Another advantage is the SSL VPN traffic is able to pass through most firewalls and proxy servers without any additional configuration. Any device that has a web browser application is capable of connecting to the SSL VPN portal. This includes PDAs, Smart Phones, the Apple iPhone, laptop system and desktops systems without regard to the underlying operating system.
There are several commercial vendor implementations of SSL VPN. Juniper, SonicWall, F5, Citrix, Cisco and Microsoft are the leaders in this area. The Juniper Networks SA is the current SSL VPN market leader but the Cisco ASA, SonicWall Aventail, F5 Firepass, Citrix Access Gateway and Microsoft IAG/UAG also have substantial market share. Each system has specified strengths and weakness points.
Usage of SSL VPN Solutions as a B2B portal
Setting up the B2B portal does require complex planning and documentation. Once the decision on which vendor best suits the needs of the implementation, the next step is to determine the “who, what and when”. The “who” refers to entities that require access. Once the determination of who is going to be given access to the internal network through the SSL VPN portal, accounts with passwords must be created and securely delivered to the intended recipient. The “what” is the determination of the items the client will have access and which protocols are to be used. Another consideration will be the level and privilege of the access to the intended resources on the extranet. The “when” are the times access will be allowed. It is at this point when this basic information has been collected, policies should start to be formed.
In figure 3, we see an example of a Microsoft IAG SSL VPN portal.
In this screenshot, the user has the ability to launch an application, such as an EDI program, go to extranet web sites, and even explore file on a predetermined server dictated by the profile of the user attributes. The client system has not passed the endpoint detection but the policy in this instance doesn’t require it and has a link to send it to remediation.
B2B portals can be set up for partner access, vendors, distributors, suppliers, logistics services and even for privileged client access. Using a single SSL VPN portal for all of these entities is entirely possible to accomplish due to that attributes of the user. For instance, a supplier could log into the SSL VPN portal and the only systems published to his profile could possibly be the ERP system and web site showing product storage capacity levels. The supplier would not have access to the CRM, distribution lists or any other system that would constitute data leakage. This is a distinct advantage over other VPN solutions where the user would have unencumbered access to the network and each individual system would have to be responsible for the access rights to allow or deny access to data. The problem is that unscrupulous individuals had the ability to prowl the network to discover the systems exposed on the extranet or in other situations, the internal corporate network.
Conclusion
The SSL VPN solution is becoming the best available in a world filled with a disparate systems requiring only a web browser to facilitate the connection. Client access could be behind a proxy or firewall, from a kiosk, or any other Internet connected device. A partner could collaborate on strategic projects on a Project Server while a distributor could upload orders via a CRM solution using the same SSL VPN portal with their sessions and traffic segregated. Data sent across the public network is cryptographically encrypted in the TLS protocol. The portal can be deployed in both the simple and complex extranets topologies as well as allowing controlled access to resources on the internal network.
References
Aboda, B., Simon, D., & Eronen, P. (2008, August). RFC 3748 Extensible Authentication Protocol (EAP) Key Management Framework. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc5247.txt
Allen, C., & Dierks, T. (1999, January). RFC 2246 The TLS Protocol. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc2246.txt
Dierks, T., & Rescorla, E. (2008, August). RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2. Retrieved October 29, 2009, from IETD: http://www.ietf.org/rfc/rfc5246.txt
Kent, S., & Atkinson, R. (1998, November). RFC 2401 Security Architecture for the Internet Protocol. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc2401.txt
Kolar, T., Littlewood, M., & Valencia, A. (1998, May). RFC 2431: Cisco L2F. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc2341.txt
Ling, R. R., & Yen, D. C. (2001). Extranet: A New Wave of Internet. SAM Advanced Management Journal , 66 (2), p39, 6p.
Maier, P. Q. (2000). Ensuring Extranet Security and Performance. Information Systems Management , 17 (2), pp33-41.
Pall, G. S., Palter, B., Rubens, A., Townsley, W. M., Valencia, A. J., & Zorn, G. (1999, August). RFC 2661 L2TP. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc2661.txt
Rescorla, E. (1999, June). RFC 2631 Diffie-Hellman Key Agreement Method. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc2631.txt
Romkey, J. (1988, June). Request for Comments: 1055 A NONSTANDARD FOR TRANSMISSION OF IP DATAGRAMS OVER SERIAL LINES: SLIP. Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc1055.txt
Simpson, W. A. (1994, July). RFC 1661: Point-to-Point Protocol . Retrieved October 29, 2009, from IETF: http://www.ietf.org/rfc/rfc1661.txt
Zorn, G., Taarud, J., Little, W. A., Verthein, W., Pall, G. S., & Hamzeh, K. (1999, July). RFC 2637 Point-to-Point Tunneling Protocol (PPTP). Retrieved October 29, 1009, from IETF: http://www.ietf.org/rfc/rfc2637.txt
No comments:
Post a Comment