Docstoc

A Comparative Analysis of IPSec and SSL

Document Sample
A Comparative Analysis of IPSec and SSL Powered By Docstoc
					             A Comparative Analysis of IPSec and SSL
       Christian Blaafjell, Mei-Pin Lan, John O’Dwyer, Hong Jieh Daniel Yang
                       blaafjel@colorado.edu lan@colorado.edu
                      odwyer@colorado.edu hyang@colorado.edu

1 Introduction
The Internet was originally based upon trust. The Internet Protocol (IPv4) trusts the
sender of the packet. IPv4 trusts that the sender of the packet is the actual sender. IPv4
trusts the packet has not been changed in transit. Most importantly, IPv4 trusts no one
else has viewed a packet during transmission.

Electronic commerce (e-commerce) spawned the need for Internet security for World
Wide Web (WWW) transactions. Many different protocols were developed to secure e-
commerce. These include Secure HTTP (S-HTTP), Secure Electronic Transactions
(SET) and Secure Socket Layer (SSL). From its beginning as a WWW security protocol,
SSL is now the predominant Internet security protocol.

As the utility of the Internet expanded, users wanted not only to send secure transactions
across the Internet but also wanted to secure complete connections across the Internet in
the forms of Extranets and Virtual Private Networks (VPNs). To take care of the need
for a standardized Internet security protocol, the Internet Engineering Task Force (IETF)
decided to include a network layer security protocol into the new version of the Internet
Protocol, IPv6. This security protocol is simply called Internet Protocol Security, IPSec.

2 The Goal
The goal of this paper is to compare the predominant Internet security protocol, SSL, and
the up and coming contender, IPSec.1 SSL and IPSec are located at different layers of the
Open Systems Interconnect (OSI) model. For this reason they have different advantages
and disadvantages.

We will compare and contrast theses two protocols by outlining a set of discriminators
that we will use to compare the protocols. We will then present the networks where SSL
and IPSec are presently optimal, followed by background information on SSL and IPSec.
Next, we will compare and contrast SSL and IPSec based on the outlined discriminators.
Finally, we will reach the conclusion that IPSec will take over as the predominant
security protocol but SSL will survive in certain niches.




1
  IPSec is considered the next logical step in Internet security since it is included in the probable
replacement, IP version 6 (IPv6), to the current version of the Internet Protocol, IP version 4 (IPv4).


                                                      1
3 The Discriminators

To help us compare and reach a conclusion about the future of the two Internet security
protocols, we have come up with four discriminators. They are as follows:
• Interoperability: The ability for the protocol to transcend products and networks.
• Layout and Security Features: Where the protocols sit in the OSI model and how that
   effects their features.
• Scalability: How capacity/load effects performance.
• The IPv6 Factor: How the new generation of IP will impact the use of SSL and IPSec.

4 The Networks

This section will describe the networks that SSL and IPSec secure.

4.1 VPNs

The Internet is as a public network that everyone shares. VPNs allow a corporate user to
use this public network privately. A VPN is a “connection” between two devises over
which private data traffic flows. Thus, instead of leasing expensive physical connections,
VPNs allow organizations to extend their network services to branch offices and remote
users through the use of the Internet. These organizations are creating a private WAN
(Wide Area Network) via the Internet [21].

Tunneling is used to create a secure VPN. Tunneling enables distributed private networks
to communicate securely over “untrusted”, public networks [22]. IPSec is ideal for
tunneling since IPSec resides in layer 3 of the OSI Model and tunnels are established at
this layer. IPSec requires one sequence of handshakes to establish a connection. Because
of this, IPSec allows the transmission of large amounts of data with low overhead based
on source and destination addresses.

4.2 Extranets

When a VPN is used to communicate from within an organization to the outside, it is
called an Extranet. An Extranet uses Internet-based protocols such as TCP (Transmission
Control Protocol)/IP (Internet Protocol). Through Extranets, users can share business
information securely with suppliers, vendors, partners, customers, etc. Extranets can be
seen as extensions of a private Intranet2 to users outside an organization. Since Extranets
provide interconnection to those outside the corporation, a higher layer security protocol
is advisable to allow for greater access control. SSL requires a "handshake" at the
session layer. If the service were trusted, checks at this layer would be inefficient.
However, since outside parties, such as customers, interconnect to the Extranet, session
layer handshakes are appropriate.



2
    An Intranet is simply a small-scale version of the Internet operating within an organization.


                                                        2
In general, Extranets foster competitive advantages such as increased revenues and
                                                              s
simplified business management by extending a company’ private network to its
business partners. For example, manufacturing companies can extend the benefits of
inter-enterprise computing to production and design partners using an Extranet, by using
the Internet at a fraction of the cost of dedicated physical connections [4]. Furthermore,
Extranets can help companies enhance customer service by opening up information and
systems on their private networks to customers. As an example, Federal Express
provides a Web-based Extranet system that allows customers to track their own packages.

5 The Protocols

This section will discuss the background, functionality and handshakes of SSL and IPSec.
This will serve as a background for comparing the two protocols

5.1 Definitions

Before discussing SSL and IPSec a few terms musts be defined for use in the discussion
of the protocols.

CA: Certificate Authority is a trusted third-party organization that issues digital
certificates that are used to create digital signatures and public-private key pairs [15].
AC: Access concentrator is a chassis-based system, which provides high bandwidth
connectivity using a combination of Basic Rate and Primary Rate ISDN, Leased Line
(WAN) and analog connections [15].
SS: Security server
CHAP: Challenge Handshake Protocol, an authentication method that can be used when
a connection is made to an Internet Service Provider [15].
TT: Tunnel terminator is an endpoint of the VPN tunnel such as a router.
Public key encryption: Assume public key is noted as k1, private key is noted as k2, and
message is noted as c. A public/private key pair is two set of numbers that can be
generated by a mathematically algorithm that k1{k2[c]} = c and k2{k1[c]} = c.
Symmetric key (session key): Two public/private key pairs that are used in one specific
session, the key pair expires when the session terminated. Two participants will keep
their own private keys and exchange public keys. Session keys are only known by the
two participants.
Certificate (digital signature): To make sure a message is from a specific sender, the
message must be encrypted with sender's private key and decrypted by sender's public
key. The receiver can download the sender's public key from a trusted CA. To
authenticate the sender, the receiver checks the certificate expiration date, the name of
CA, and sender's public key.
Master secret: a number that is used to generate a pair of session keys.
Premaster secret: a message that describes the way to generate the master secret.
Internet Key Exchange: The IKE manages the Security Association in IPSec. This
process consists of authenticating peers in an IPSec transaction, negotiating security
policies, and handling the exchange of session keys.




                                            3
5.2 Similarities Between IPSec and SSL Cryptography

Both IPSec and SSL support a variety of different cryptographic algorithms, or ciphers
[8][7]. Ciphers include the encryption and data authentication algorithms that are used in
the handshaking methods of IPSec and SSL. Handshaking is discussed later in this paper.
Cipher suites are sets of cipher algorithms that are decided upon during the handshake
between the client and server. Cipher suites decide on the strength of the encryption of
the data and how the client and servers are authenticated. Ciphers include DES, Digital
Signature Algorithm (DSA) and Key Exchange Algorithm (KEA).

The cipher suites used by IPSec and SSL are based upon public-key cryptography.
Public-key is made up of a public-key, which is used to encrypt information, and a
private-key, which is used to decrypt information. The public-key is used by anyone that
wants to interact securely with the user of the private-key. The private is kept secret so
only the user can decrypt information.

5.3 IPSec background

Due to the needs of a secure Internet and an open Internet security standard, the Internet
Engineering Task Force (IETF) developed the IPSec protocol in 1996. IPSec works in the
network layer. It provides cryptographic security services that are designed to support the
combinations of authentication, integrity, access control, and confidentiality. The goal of
IPSec is to secure host-to-host, subnet-to-subnet and host-to-subnet transactions [19].

IPSec can be used in either transport mode or tunnel mode [9]. The transport mode
provides security between a source and destination addresses yet packets are routed in the
same manner as traditional IP packets. The tunnel mode works by establishing secure
tunnels between the source and destination. The user defines which packets are to be
secured, and these packets are then sent through the tunnel. The tunnel is defined by the
methods used to secure the packets; the methods are authentication, integrity, and
encryption.

The methods used in providing security for the tunnel are called Security Associations
(SA). The SA decides if the protocol used is going to be AH or ESP (AH and ESP are
described later) and which security algorithm should be used on the packet.

In a router, IPSec works by applying access lists to different interfaces through the use of
crypto map sets [9]. A crypto map set contains different security protocols such as IPSec
or CET (Cisco Encryption Technology). When a packet matches an entry in an access
list, the crypto map is searched in order to decide which security protocol is going to be
applied to the packet. Depending on the entries in the crypto map, the appropriate
security protocol is selected. The same happens for incoming packets. In the case of
IPSec, the next step depends on if a SA exists to protect the packets. If a SA exist, the
SA is applied to the triggering packet and all subsequent packets that meet the same
access list criteria as the first packet. In the case where no SA exists, IPSec uses Internet
Key Exchange (IKE) and a series of handshakes to negotiate the appropriate SA with the


                                              4
remote peer. The negotiation is based on the information contained in the crypto map
and the data flow information in the access list. To add additional security, the SA’   s
periodically expire and require renegotiations after a certain time. If the entries in the
crypto map specify manual configuration of IPSec, and no SA exists, the traffic is
dropped [9]. Generally, multiple IPSec tunnels can exist between two peers using
              s
different SA’ to allow for multiple combinations of encryption, integrity, and
authentication.

The IPSec protocol introduced two main components, Authentication Header (AH) and
IP Encapsulation Security Payload (ESP). The AH provides data origin authentication,
connectionless integrity, and anti-replay protection services, but confidentiality for IP
datagrams [11].

             0                                                                31
                 Next Header   Payload Len              Reserved
                             Security parameters index (SPI)
                                 Sequence Number Field
                           Authentication Data (variable length)
                                Figure 1: The AH Format

ESP header is designed to provide a mix of IPv4 and IPv6 security services. ESP can be
applied alone, with AH, or in a capsulated mode. Unlike AH, ESP does not protect IP
header fields unless the fields are encapsulated by ESP. ESP provides authentication
function as AH and confidentiality which AH does not apply [11].

             0                                                                31
                             Security Parameters Index (SPI)
                                    Sequence Number
                              Payload Data (variable length)
                   Padding (0-255 bytes)      Pad Length      Next header
                          Authentication Data (variable length)
                                  Figure 2: ESP format

5.4 SSL background

Netscape developed SSL in July 1994 to meet the occurring need of Internet security. It
has been widely accepted on the World Wide Web and is now the de facto standard for
Internet encryption. SSL was approved as the standard Internet secure protocol by the
IETF in early 1996. SSL is platform and application independent, and resides
approximately between the application and transport layers in the OSI model. The goal
of SSL is authenticated and encrypted communication between clients and servers [8].
SSL is a rather mature encryption mechanism compared to IPSec. SSL v2.0 was
introduced in December 1994, and SSL v3.0 was released in November 1995. To secure
a connection, SSL uses public keys, session keys, and other symmetric encryption
algorithms such as RC4 and DES for data encryption [17]. The encryption takes place
right after the initial handshake.


                                              5
5.5 IPSec handshake

The following figure and numbered steps describe the IPSec handshake.




                                  ISP's POP

  Remote                               2
   user                                         SS
                  1                         3
                      4         AC

                                                          5
                                                     6                TT


                                TT's
                          public key       CA            AC's
                                                         public key


                              Figure 3: The IPSec Handshake


1. To set up a tunnel, the remote user sends a CHAP message to the AC that contains the
   user name and password.
2. The AC sends the user name and the password to the SS for a user check.
3. When the SS is done with the user authentication, it sends the IP addresses and subnet
   masks of the two ends of the tunnel to the AC.
4. The AC sends a CHAP message to the remote user with both the IP addresses and
   subnet masks.
5. The AC sends a digital signature to the TT with a message stating that both the AC
   and TT use the Internet Security Association Key Management Protocol
   (ISAKMP)/Oakley protocol to agree on the encryption algorithms and data
   authentication algorithms. The TT can read the message by downloading AC's public
   key from a CA.
6. The TT sends back a digital signature with a confirmation of receiving the previous
   message. The AC can read the message by downloading the TT's public key from a
   CA.
7. The Handshaking is finished. A tunnel is formed from TT to the recipient side's TT.
   The algorithm stated in step 5 will encrypt all data transmitted from one end of the
   tunnel to the other [16].




                                                6
5.6 SSL handshake

The following figure and numbered steps describe the SSL handshake.


       CA                                      1
                                                                                       CA
                                                           2
       Server's        Client          3                              Server
     public key                                                                    Client's
                                                                                   public key
                                                   4
                                                       5
                                               6
                                           7

                                Figure 4: The SSL Handshake

1. To establish a connection, the client sends its SSL information (SSL version number,
   cipher settings, randomly generated data, etc) to the server.
2. The server sends its own SSL information with a digital certificate to the client. The
   client can read the message by downloading the server's public key from a CA.
3. The client sends back its digital signature with a premaster secret. The premaster
   secret is encrypted by the server's public key. Therefore, it is readable only to the
   server. When both sides authentic each other's identity, both sides generate a master
   secret the way stated in premaster secret. Two pairs of symmetric keys will be
   generated.
4. The client sends a message stating that all data afterward will be encrypted with a
   session key.
5. The client sends a message that the handshake is finished.
6. The server sends a confirmation that all data sent now will be encrypted with the
   session key.
7. The server confirms that the handshake is finish [8].

5 Discussion of the Discriminators

This section will compare and contrast SSL and IPSec using the discriminators presented
at the beginning of the paper. This discussion will act as a basis for our conclusion.

5.1 Interoperability

Major Web server vendors such as Netscape, Microsoft, and Apache all support SSL, and
it is easily incorporated into UNIX [5]. This is good for the interoperability between
most Web browsers and servers. On the other hand, other applications that want to
include SSL have to implement SSL separately. This means SSL is not interoperable
across applications [2].


                                               7
IPSec is an emerging IETF standard and it is going to be the security protocol for IPv6
[7]. Therefore, the protocol allows multivendor interoperability among network devices
and PCs. IPSec does not have the same problem of interoperability that SSL has. Since
IPSec resides at the network layer, individual applications do not have to worry about
implementing IPSec.

On the contrary, theoretical predictions not always meet real life applications. IPSec still
lacks the interoperability needed to succeed, especially in the VPN market [5]. As an
example, according to the International Computer Security Association, which is
                                                       s
conducting IPSec testing for the automotive industry’ Automotive Network Exchange
[5], the “timeout” mechanism in the public-key exchanges of different IPSec vendors
               t
products didn’ work together. Without the “timeout”, weaker keys can be used for a
long time, giving a hacker more time to break the encryption.

5.2 Security Features and Layout

Both protocols are encryption independent. The major difference between the two
protocols is at what level they reside on in the OSI model. SSL is implemented in the
session layer, above TCP, below the application layer. Because of its location, access
control is based not only on packet filtering, but other factors such as user identity,
application and/or service, authentication method, encryption algorithm, and time and/or
date. This gives SSL a higher granularity of access control. The downside to having the
protocol at a higher level in the OSI model is that the application needs more overhead
processing. This is the case since each session set up between a client and server must
initiate its own handshake.

IPSec uses packet filtering as its access control [6]. Since it only uses source address,
destination address, and the port of the source and destination address [23], the access
control is limited as far as granular control of the packets. The advantage is that the
processing time decreases in hand shaking, since only one sequence of handshakes are
required, and larger amounts of data can be processed. As far as authentication goes,
IPSec currently supports digital signatures and digital certificates. The protocol is
inferior in areas such as access control [12].

5.3 Scalability

In the case of SSL, scalability pertains to the fact that each connection to an application
requires separate handshakes. As the number of clients establishing connections to the
remote end increases, additional processing power is shifted towards establishing
connections through handshakes, resulting in slower response time for ongoing
connections [8].

For IPSec, the problem of scalability pertains to the Internet Key Exchange (IKE) and the
fact that IPSec uses public key encryption [4]. IPSec is the chosen Internet security
protocol for IPv6. One of the major problems that IPv6 is going to solve is the lack of IP



                                              8
addresses in IPv4. IPv6 is solving this by increasing the address space from 32 bits to
128 bits. Along with this comes the possibility of an increasing number of users wanting
to use IPSec to encrypt the data. As the number of users using IPSec increases, so does
the number of public and private keys that has to be managed. The solution to how to
manage the increasing number of electronic keys has not yet been solved and is seen as
the major obstacle for the success of IPSec [6]. As of now, the keys used in IPSec are
distributed manually.

5.4 The IPv6 Factor

It seems as if the integration of IPSec into IPv6 is going to be the deciding factor for the
success of IPSec. With the integration of the two, consumers have access to a security
protocol without downloading additional files, making the chance of acceptance by the
                                        s
consumer more likely. In addition, it’ only a matter of time before IPv6 has to be
implemented since we are rapidly running out of IP addresses and through this the
implementation of IPSec. A third factor is that IPSec is currently being used with IPv4
[10], making the transition to IPv6 much easier since many of the bugs and problems
related to the security protocol will have been solved by the time IPv6 is put into use.

6 Summary of the Results

The features of IPSec and SSL are mostly based upon two major factors, where the
                                            s
protocols reside in the OSI model and IPSec’ inclusion in IPv6. The following table
summarizes the features of IPSec and SSL that were compared in the discriminators.

                   Table 1: A Comparison of IPSec and SSL Features [2]

Feature                 IPSec                              SSL
Protection              Protects the IP packet             Protects applications
Packet Filtering        Based on source and                More granularity and control of
                        destination addresses, suitable    the application layer
                        for routers
Performance             Faster due to one handshake        Handshake for each connection
                        for the entire connection          between applications, more
                        between endpoints                  overhead
Platform                Supported by any system            Ideal for client/server
                                                           applications
Current uses            Emerging VPN security              Standard WWW security
                        protocol                           protocol
Scalability             Large number of public keys        Increasing processing needs with
                        in IKE                             increasing open sessions
IPv6                    Inclusion in IPv6                  Cannot be included in IPv6 since
                                                           it is a session layer protocol

One can conclude for the table that both IPSec and SSL both have advantages and
disadvantages due to the factors discussed earlier. Since IPSec resides at the network


                                              9
layer, it only needs one handshake between source and destination addresses. This gives
it better performance and lower overhead on large amounts of data than SSL. This makes
it better security protocol for VPNs. On the other hand, it lacks the access control due to
                    s
its position. SSL’ access control makes it better protocol in Extranets where this extra
access control is needed.

Since each protocol has its advantages and disadvantages due to where they reside in the
                                                                            s
OSI model, the deciding factor on the future of the two is probably IPSec’ inclusion in
             s
IPv6. IPSec’ inclusion in IPv6 has one drawback, the IKE problem discussed earlier.
The incredible advantage that this inclusion gives IPSec is that inclusion in IPv6 makes it
interoperable with any other system that uses IPv6. Since this is the case and the only
real drawback to IPSec is it lack of access control, we believe that IPSec will prevail as
the predominant Internet security protocol and SSL will become a niche security protocol
where greater access control is needed.

7 Conclusion
Do to the difference in characteristics of IPSec and SSL, they both have advantages and
disadvantages in different types of networks and situations. Since IPSec is a network
layer protocol, it is better at transferring large amounts of data. The position of IPSec
also gives it the disadvantage of not being able to control user security levels to the
degree that SSL, its application layer counterpart, can. Therefore, IPSec is better for
intra-corporation networking, while SSL can give the variable security levels needed that
can expose only parts of an Intranet. Making it a better solution for Extranets.

Even though SSL has its advantages, the predicted implementation of IPv6 will change
the outlook of the Internet security market. Since IPSec will be integrated into IPv6,
IPSec will slowly replace SSL. We believe this will be the case since IPSec’  s
advantages, with the integration into IPv6, will out-weight the advantage of SSL.

References

[1] “A Primer for Implementing a Cisco Virtual Private Network (VPN)”, Cisco
Technical Paper, March 15, 1999 (can be found at
http://www.cisco.com/warp/public/779/largeent/vpne/vpn21_rg.htm).
[2] P.C. Cheng, J.A. Garay, A. Herzberg, H. Krawczyk “A security architecture for the
Internet Protocol” IBM Technical Paper, February 8, 1999 (can be found at
http://www.almaden.ibm.com/journal/sj/371/cheng.html).
[3] F. Derfler, "Your Private Internet",
http://www1.zdnet.com/pcmag/pclabs/nettools/1720/index.html, November 17, 1998.
[4] “Extranet FAQ”, March 13, 1999 (can be found at http://www.extranet-faqs.com/).
[5] “Extranet Security and Management: The Difference Between Extranets and VPN’    s,”
Aventail Technical Paper, March 8, 1999 (can be found at
http://aventail.com/index.phtml/solutions/tech_briefs/Extranets_vs_vpns.phtml).




                                            10
[6] “Extranet Security and Management: IPSec vs. SSL” Aventail Technical Paper,
March 8, 1999 (can be found at
http://aventail.com/index.phtml/solutions/tech_briefs/ipsec_ssl.phtml).
[7] C. Huitema, Ipv6, The New Internet Protocol, Upper Saddle River; Prentice-Hall
PTR, 1998, pp 145-228.
[8] “Introduction to SSL,” Netscape Technical Paper, October 9, 1998 (can be found at
http://developer.netscape.com/docs/manuals/security/sslin/contents.htm).
[9] “IPSec Network Security” Cisco Technical Paper, May 2, 1999 (can be found at
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/ipsec.htm#xtocid25946).
[10] “IP Security-IPSec” Cisco Technical Overview Paper, June 13, 1998 (can be found
at http://www.cisco.com/warp/public/732/Security/ipsec_ov.htm).
[11] S. Kent, “IP Encapsulating Security Payload (ESP),” http://www.vpnc.org/rfc2406,
1998.
[12] J. Kerstetter, “IPSec VPN standard hits speed bumps,”
http://search.zdnet.com/pcweek/news/0511/11ipsec.html, November 5, 1998.
[13] D. Larson, “The Race to Secure Cyberspace,”
http://www.webdeveloper.com/security/security_race_cyberspace.html, March 8, 1999.
                                        s
[14] R. Moskowitz, “Ipv6 For VPNs: It’ Looking Better All The Time,”
http://www.nwc.com/901/901colmoskowitz.html, March 16, 1999.
[15] H. Newton, Newton’ Telecom Dictionary, 14th Expanded Edition, New York,
                           s
Flatiron Publishing, 1998. pp. 147-149.
[16] “Private Use of Public Networks for Enterprise Customers,” 3Com Technical Paper,
March 2, 1998 (can be found at
http://www.3com.com/technology/tech_net/white_papers/500651.html).
[17] “Secure Sockets Layer Protocol,” IBM Technical Paper, February 23, 1999 (can be
found at http://www.ibm.com/security/html/techsslp.html).
[18] P. Tate, "VPNs: Very pertinent networks--to you,"
http://www.zdnet.com/pcweek/opinion/0330/30corner.html, March 30, 1998.
[19] “Virtual Private Networks and IPSEC,” IBM Technical Paper, February 23, 1999
(can be found at http://204.146.18.33/security/html/techvpn.html).
[20] B. Walsh, "Cash and Confidence on The Web",
 http://www.nwc.com/904/904colwalsh2.html, March 1,1998.
[21] "What is a VPN", http://www.vpncon.com/whatarevpns.htm, April 2,1999.
[22] “What is IPSec”, IPSec Developers Forum Technical Paper, March 7, 1999 (can be
found at http://www.ip-sec.com/IPSec_Info.html).
[23] N. J. Yeager, Web Server Technology, San Francisco; Morgan Kaufmann Publishers,
Inc., 1996, pp. 313.




                                                 11

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:36
posted:8/27/2011
language:English
pages:11