An Application Level Emulation of IPSEC
by
Chad F. Jones
Submitted to the Department of Electrical Engineering and Computer Science
in partial fulfillment of the requirements for the degrees of
Bachelor of Science in Computer Science and Engineering
and
Master of Engineering in Electrical Engineering and Computer Science
at the
MASSACHUSETTS INSTITUTE OF TECHNOLOGY
June 1998
@
Massachusetts Institute of Technology 1998. All rights reserved.
Department ofilectrical Engineering and Computer Science
May 22, 1998
Certified by...
.. :...
..
.:....
Certified by ... , ... . ..
.... ... . . .. .. .. . .. . . . .. . ....
Dr. Thomas M. Parks
MIT Lincoln Laboratory
Thesis Supervisor
.... .. ... ... ...
Dr. Clifford J. Weinstein
MIT Lincoln Laboratory
Thesis Supervisor
-Accepted by...
MASSACHUSETTs INSTIr .'r OF TECHiN,~ ,"-•JUL 141f8
l
LIBRARIES...
Departmen
ommittee
on"
-..
:
Gradt
tUhur C. Smith
...
S
-..
Chairman, Department Committee on Graduate Theses
An Application Level Emulation of IPSEC
by
Chad F. Jones
Submitted to the Department of Electrical Engineering and Computer Science on May 22, 1998, in partial fulfillment of the
requirements for the degrees of
Bachelor of Science in Computer Science and Engineering and
Master of Engineering in Electrical Engineering and Computer Science
Abstract
This thesis describes the design of an application level emulation of the Internet Protocol Security (IPSEC) standards. The emulation has been incorporated into the MASH toolkit, developed at the University of California at Berkeley. The emulation is based upon the Request For Comments and Internet Draft documents published by the Internet Engineering Task Force. The application level emulation will be used to explore the issues of using IPSEC with collaborative multicast tools. Additionally, it has been evaluated to determine the costs of using this implementation and analyzed to see how closely it should compare to a network level implementation.
Thesis Supervisor: Dr. Thomas M. Parks Title: MIT Lincoln Laboratory
Thesis Supervisor: Dr. Clifford J. Weinstein Title: MIT Lincoln Laboratory
Acknowledgments
I would like to acknowledge the many people who made this thesis possible. My advisors, Cliff Weinstein and Tom Parks, helped me down the research path and asked all the questions I would have initially avoided. I would like to thank Ed Johnson, Evan Fortunato, Valerie Hovland, and Abigail Vargus for keeping me from going insane and/or letting me bounce ideas off of them. I would also like to thank Mom and Dad, Bruce and Rebecca Otsea, for nagging me about my incomplete in 6.868 so that I did not forget it during thesis time. Many thanks also go to MIT Lincoln Laboratory for sponsoring my research for the last year. And lastly, I would like to thank MIT for providing an educational environment that I am both sad and overjoyed to leave behind.
Contents
1 Introduction 7
2 IP Security 9
2.1 Authentication and Integrity ... .. ... ... 9
2.2 Confidentiality ... ... . 10 2.3 Key Management ... ... ... .. 11 2.4 Related Work ... ... . . 13 3 Multicast Security 14 3.1 Authentication ... ... . 14 3.2 Key Management ... ... ... .. 15
3.2.1 Repeated Two-Party Exchange ... ... 15
3.2.2 Security Association Database ... ... 15
3.2.3 Multi-Party Exchange ... ... 16
3.2.4 Managing Dynamic Group Membership ... .. 16
4 Design and Implementation 17 4.1 The MASH Toolkit ... ... ... ... 18
4.2 Authentication ... ... . 18
4.3 Confidentiality ... ... . 20
4.4 Key Management ... ... ... .. 23
4.4.1 Security Associations ... ... 23
4.4.2 Mashkey ... ... . 23
4.4.3 Security Association Server ... ... . 24
4.5 Status ... ... ... 25
5 Evaluation 26 5.1 Performance ... ... ... 26
5.1.2 Bandwidth Overhead ... ... 27
5.1.3 Encryption Processing Overhead ... ... 31
5.2 Security Analysis ... ... .. 33
5.2.1 Exploiting Vulnerabilities ... ... . 33
5.2.2 Hardening Application-level IPSEC ... .... 35
List of Figures
1-1 Security protocols above the transport layer.
Format of an AH datagram . ...
AH header format . ...
Format of an ESP datagram in tunnel mode. Format of an ESP datagram in transport mode. Encapsulating Security Payload header format.
ISAKMP Header . ...
Object diagram for CryptAH... Format of our AH datagram. Our AH header format... Object diagram for CryptESP.
Format of our ESP datagram. .
Our ESP header format. ...
Security Association management architecture. 2-1 2-2 2-3 2-4 2-5 2-6 4-1 4-2 4-3 4-4 4-5 4-6 4-7 5-1 5-2 5-3 5-4 5-5 5-6 5-7 5-8
vic Data Stream with Default Quality Settings ... vic Data Stream with High Quality Settings ... vic Data Stream with High Quality Settings ... Synthesized vic Data Stream with High Quality Settings
vat Data Stream with DVI encoding . ...
Synthesized vat Data Stream with DVI encoding . . .
Encryption with DES ...
Chapter 1
Introduction
The goal of this thesis is to explore some of the issues associated with secure IP multicast [7]. Multi-media teleconferencing was chosen as the application to drive the experiments. The Internet Security protocols are a standard for providing security to IP datagrams. For multimedia teleconferencing, these IP datagrams must be multicast to handle the bandwidth requirements. For this thesis, an application-level emulation of the Internet Security protocols was developed for experimentation with secure multicast.
The Internet Security, IPSEC, protocols [3] were designed to provide authentication, integrity, and confidentiality to IP datagrams. IPSEC was intended to be used mainly with unicast trans-missions. Although use for multicast is mentioned in these protocols, using the Internet Security protocols for multicast is still largely experimental.
Secure multicast transmission of IP datagrams requires several security considerations not present with unicast traffic. Authentication and integrity must be provided for all traffic in the group but asymmetric algorithms must be used so that members can not forge traffic from another member. Efficient group key management is also very important and is currently a topic of research. Se-curity for multicast groups is inherently more complex for both of these issues because the group membership is dynamic.
An application-level emulation of the Internet Security protocols was developed for experimen-tation with secure multicast. Since current IPSEC implemenexperimen-tations are still in development and are operating system specific, the application-level emulation was designed for ease of experimentation on a variety of platforms. Additionally, current IPSEC implementations are designed to allow legacy applications to run unmodified. The application-level emulation requires that the application is mod-ified to be security-aware. Since the API to IPSEC is not yet standardized, the application-level emulation may help to determine an API that will be useful for security-aware group communication applications.
The goals of application-level security will vary with the specific application that is being used. Providing security at the application-level to a general TCP connection is currently being addressed by the Transport Layer Security working group of the Internet Engineering Task Force. Providing security for UDP traffic, as shown by the question mark in Figure 1-1, has not been generalized yet. Currently, applications that need security for UDP traffic provide for it with a very application specific mechanism. The work that was done for this thesis on an application-level emulation of the
IPSEC standards could provide a general way of handling the security of UDP traffic.
HTTP RTP
I I
SSL ?
I I
TCP UDP
Figure 1-1: Security protocols above the transport layer.
The MASH Toolkit [15] is being used as the basis for the experiments. The MASH Toolkit has evolved from popular multicast audio (vat), video (vic), and whiteboard (mb) conferencing applications. The emulation of the IPSEC protocols is implemented within the object-oriented framework of this toolkit. This is a relatively general purpose approach because it may be reused for any application built with the toolkit.
Chapter 2
IP Security
The Internet security protocol standards were originally published in August 1995 [3, 1, 2]. Revi-sions to the standard are currently in preparation [12, 10, 11]. The architecture provides a general framework for providing integrity, authentication, and confidentiality for network communications.
Before parties can communicate securely, they need to decide on the algorithms, the modes, and the keys to be used. With the Internet security protocols, this information forms a Security Associ-ation. For authentication, the Security Association must contain the authentication algorithm, the algorithm mode, and authentication key. For confidentiality, the Security Association must contain the encryption algorithm, the algorithm mode, the transform of the algorithm, the encryption key, and the initialization vector. For both authentication and confidentiality, the Security Association is recommended to contain the lifetimes of the keys, the lifetime of the Security Association itself, the IP source addresses, and a sensitivity label. Each Security Association is uniquely identified by a Security Parameters Index (SPI) and an IP destination address.
The Internet Security Association and Key Management Protocol [14] is defined for the creation and management of security associations. The Authentication Header (AH) [1] provides integrity and authentication. The Encapsulating Security Payload (ESP) [2] provides confidentiality.
2.1
Authentication and Integrity
The IP Authentication Header (AH) [1] provides integrity and authentication without confidential-ity. The AH is useful for data that does not need to be or should not be encrypted but should be authenticated. Since encryption is not used, the algorithms used with AH are not subject to restrictions on import, export, or use of encryption technology.
Figure 2-1 shows the location of AH in the case of IPv4. The internal format of the AH is determined by the authentication algorithm that is being used. Figure 2-2 shows the structure for the AH when it is used with MD5 [16], where each row is 4 octets or 32 bits long. The SPI
Figure 2-1: Format of an AH datagram.
Next Header Length Reserved Security Parameters Index
Authentication Data
Figure 2-2: AH header format.
together with the destination address in the IPv4 header identify the Security Association that is used. In the case of using MD5 [16], the authentication data in the AH is the 128 bit output of the MD5 algorithm. In general, the data is a multiple of 32 bits and varies in length depending on the authentication algorithm.
2.2
Confidentiality
The IP Encapsulating Security Payload header (ESP) [2] provides confidentiality. There are two modes that the ESP header can be used in with IPv4 datagrams. In the first, called transport mode, the ESP header follows the IPv4 header and encapsulates only the rest of the datagram. In the second, called tunnel mode, the ESP header encapsulates the IPv4 header and adds a minimal IPv4 header to the front of the datagram. All the data that is encapsulated by the ESP header is encrypted. IPv4 Header ESP Header IPv4 Header Transport Header Payload
Figure 2-3: Format of an ESP datagram in tunnel mode.
In Figure 2-3, the ESP header in tunnel mode is shown for IPv4. Tunnel mode is used when confidentiality is only needed between two gateways. In the case of a Virtual Private Network (VPN), the ESP header can be applied only at the gateways connecting the separate sites to the untrusted network. The host computers that are behind each of the gateways do not need to be
IPv4 Header Authentication Header
Transport Header Payload
modified and can rely on the gateways to provide confidentiality for all of the datagrams.
Figure 2-4: Format of an ESP datagram in transport mode.
In Figure 2-4, the ESP header in transport mode is shown for IPv4. Transport mode is used when confidentiality is needed between two individual hosts. Since the ESP header follows the IPv4 header, transport mode has the benefit of providing smaller datagrams when the source and destination address information does not need to be or can not be kept confidential.
Security Parameters Index
Initialization Vector
Payload Data
Padding Pad Length Payload Type
Figure 2-5: Encapsulating Security Payload header format.
Figure 2-5 shows the ESP header when used with DES in CBC mode [9]. The SPI together with the destination address in the IPv4 header identify the Security Association that is used. The Initialization Vector (IV) can be either 32 bits or 64 bits in length. If it is 32 bits, then for DES-CBC, the IV is extended to 64 bits by concatenating this 32 bits with its bit compliment. The encrypted data, shown by the shading in the Figure 2-5, is padded with random data to the block length of the encryption algorithm, which is 64 bits in the case of DES-CBC. The padding length can exceed the minimum length to the next block boundary in order to conceal the true length of the data.
2.3
Key Management
The Internet Security Association and Key Management Protocol (ISAKMP) [14], which is currently under development, is used for establishing Security Associations for IPSEC. It provides a general framework for deciding on a security policy and exchanging key information between two hosts. The framework is independent of the authentication or encryption algorithms that are being used.
The messages for ISAKMP all consist of a series of payloads. A single message between two hosts using ISAKMP can consist of one or many payloads. A payload consists of a generic payload header and a string of octets that is opaque to ISAKMP. ISAKMP will then use Domain Of Interpretation (DOI) information to interpret these octets. In addition to the payloads, each ISAKMP message
IPv4 Header ESP Header Transport Header Payload N c
will start with the ISAKMP Header, shown in Figure 2-6.
Next Payload MajVer MinVer Exchange Flags
Message ID
Length
Figure 2-6: ISAKMP Header
The ISAKMP header is used to identify the other host, provide information on what type ex-change is being used when setting up the Security Association between the two hosts, and give some other information on the payload contents of this specific message. The general pattern that two hosts use with ISAKMP is to first setup a Security Association between themselves to establish a secure channel. The two hosts then exchange information on other Security Associations using this channel.
In the first phase of communication (using the Base Exchange type [14]), the initiating host sends a message consisting of the ISAKMP Header, a prioritized list of Security Association propos-als (which can consist of many individual payloads), and a Nonce payload to protect from replay attacks. The responding host then sends back a message consisting of the ISAKMP Header, payloads identifying the Security Association proposal that is acceptable, and a Nonce payload. If there were no proposals that were acceptable, then the initiating host has the option of restarting this dialog with a different list of proposed Security Associations.
If one of the Security Association proposals was acceptable, the initiating host sends a message containing the ISAKMP header, a Key Exchange payload, a Host Identification payload, and an Authentication payload. The responding host sends back a message with the same payloads. The Key Exchange payload supports a variety of key exchange techniques including "Oakley, Diffie-Hellman, the enhanced Diffie-Hellman key exchange described in X9.42, and the RSA-based key exchange used by PGP." [14] After this exchange, each host has authenticated themselves to the other and a key has been generated. This key is used with the previously agreed upon Security Association proposal to establish the whole Security Association. All further traffic between these two hosts for ISAKMP is protected using the established Security Association.
In the second phase of communication using ISAKMP, the two hosts can send and receive any of the previous payload types in order to establish further Security Associations. In addition, the following payload types are available:
* Certificate: used send a Certificate to another host
* Certificate Request: used to request a Certificate from another host
Initiator Cookie
* Hash: used to send the results of a hash function to the other host
* Notification: used to notify the other host of any error that has occurred
* Delete: used to send a request that a Security Association should be deleted. This can include the Security Association that is currently being used for ISAKMP messages.
These payloads, when used with the payloads also used in the first phase, provide enough func-tionality for the creation and maintenance of Security Associations between two hosts.
2.4
Related Work
The Transport Layer Security Working Group' at the Internet Engineering Task Force is involved with security on top of reliable transport protocols, such as TCP.
A version of IPSEC2 is available for Linux for the University of Arizona's x-kernel3. The x-kernel is an object-based framework for implementing network protocols.
The Naval Research Labs released an alpha version IPv6 with IPSEC4 for some 4.4BSD derived
systems in January 1998.
The DOD has released version 0.1 of their ISAKMP Distribution5. This implementation does
not implement the complete ISAKMP protocol.
Cisco Systems, Inc. has released version 0.5 of their ISAKMP Distribution6. This is meant
to be a reference implementation and is designed to work with an IPSEC using the PF_KEY Key Management API (note: the NRL IPv6 + IPSEC uses this API).
1 <http://www.ietf.org/html.charters/tls-charter.html> 2 <http://www.cs.arizona.edu/xkernel/hpcc-blue/linux.html> 3 <http://www.cs.arizona.edu/xkernel> 4<http://web.mit.edu/network/isakmp/nrlkmp-A6.html> 5 <http://web.mit.edu/network/isakmp/dodkmp.html> 6 <http://web.mit.edu/network/isakmp/ciscokmp.html>
Chapter 3
Multicast Security
The IPSEC protocols describe how to use the Authentication Header (AH) and Encapsulating Security Payload (ESP) header to provide authentication, integrity, and confidentiality to datagrams. In order to use these protocols with multicast traffic, the destination address of these datagrams is set to be a multicast address. A given Security Association then is identified by an SPI and a destination multicast address, and provides information for what is done with datagrams that are sent to that multicast address. Unfortunately, this causes a few complications with regard to authentication and key management.
3.1
Authentication
In the case of two-party, unicast communication, each party needs to authenticate himself to the other party. The authentication algorithm that is used can be based on a shared secret key. Consider an example where a datagram is received by Alice from Bob and can be authenticated with a shared secret key. In this case, Alice knows that Bob must have sent that datagram because he is the only other party that knows the shared secret key.
When AH is used with multicast traffic, the sender of that datagram needs to be authenticated to each of the receivers. The authentication algorithm can not be based on a shared secret key. Consider an example where a message is received by Alice from Carol and can be authenticated by the secret key that is shared by the group. In this case, Alice does not know if it came from Bob or if it came from Carol. The shared secret key provides authentication that the message came from a member in the group but does not authenticate the message as coming from a specific individual.
The alternative to using an authentication algorithm based on a shared secret key is to use one that is based on public-key cryptography. In this scenario, each sender has a private key that they use to digitally sign the datagrams that they send. Each of the receivers has a copy of the public key for every possible sender and can then authenticate each datagram as coming from a specific
individual. Unfortunately, public-key cryptography generally requires more processing time and the IPSEC protocols will require a separate Security Association for each of these public keys.
3.2
Key Management
In the IPSEC architecture, all of the information relevant to key management is stored in Security Associations. The management of these Security Associations becomes important for multicast. It is possible for all of the Security Associations to be manually keyed before they need to be used. However, for many applications it is desirable to be able to dynamically create, modify, and delete Security Associations. The options for managing these Security Associations fall into three categories: using repeated two-party exchange, using a Security Association database, or using multi-party exchange.
3.2.1
Repeated Two-Party Exchange
Whenever a Security Association needs to be created or modified, one host in the group will contact every other member in the group to exchange the appropriate information. If, through the ISAKMP exchange, a Security Association can not be agreed upon with one of these hosts, then the originating host will have to contact each host again in order to delete this Security Association.
The first disadvantage to this approach is that it will create a lot of traffic on the network. Secondly, since the Security Association is established between individual hosts, there is a problem with maintaining global group consistency of the Security Associations. For example, Alice contacts Bob and establishes a Security Association and then contacts Carol, who rejects the proposals for this Security Association. Alice must then contact Bob and delete the recently established Security Association and try to establish another. In general, repeated two-party exchange does not seem too useful for a multicast environment.
3.2.2
Security Association Database
In this approach, one or more servers will be responsible for maintaining the Security Association Database. The Security Association Database is similar to the Key Distribution Center used with Kerberos [13], but it has different functionality that is specifically for Security Associations. When-ever a Security Association needs to be established or modified, a host will contact one of these servers. If there is more than one server, the database should be kept consistent across the multiple servers. In addition to the information that is normally in each Security Association, there needs to be an Access Control List (ACL) for each Security Association. This will determine what hosts are allowed to access, modify, or delete the Security Association. There should also be an ACL for determining which hosts can create Security Associations.
The number of hosts that are used as SA Servers will limit the scalability of this approach. Since the amount of processing required for each client connecting to a SA Server is small, each SA Server should be able to handle a large number of clients. There is also the disadvantage of making the system less reliable because, since the SA Servers are needed to distribute, create, or modify Security Associations, the SA Servers become a possible single point of failure for the system. However, for specific uses, these drawbacks should not be the limiting factors.
3.2.3 Multi-Party Exchange
In order to get an efficient and scalable solution to managing Security Associations, a more dis-tributed approach is required. Currently, at least one form of scalable multicast key distribution [4] has been developed. This approach handles the group membership and distribution of the keys
by using a Core Based Tree (CBT) [5, 6] approach. If CBTs were used to distribute information
about Security Associations, then an arbitrary number of hosts might be able to create, modify, and delete Security Associations. A CBT approach can also be used as an alternate approach to routing multicast packets. Unfortunately, the CBT approach requires multicast routers that are able to use this new structure. The current Internet Multicast Backbone is not setup to use CBTs.
3.2.4
Managing Dynamic Group Membership
Regardless of which approach is used for the creation or maintenance of Security Associations, each Security Association should be replaced or modified with each addition or deletion of members from the group. The new Security Association is necessary for new membership to ensure perfect backward secrecy. If this policy is not enforced, then a new member would be able to decrypt any previous group traffic. Likewise, the new Security Association is necessary for deletion of members to ensure perfect forward secrecy. If this policy is not enforced, then an old member of the group can decrypt any data that is exchanged after they officially leave the group.
Multicast traffic provides several unique challenges to providing network security. There is no control over where the data may get forwarded to or where incoming data may originate. The group membership is dynamic and there are not always reliable notices of changes in the membership. The different approaches to the problem range from simple and not very scalable to complicated and completely scalable.
Chapter 4
Design and Implementation
For this project, an application-layer emulation of the IP Security protocols (IPSEC) was developed. The chosen application for this work was a distributed multimedia collaboration toolkit called the MASH Toolkit [15]. After the IPSEC protocols were partially integrated into the toolkit, a key management application was developed to interact with them. The key management application was designed to use the ISAKMP protocol to exchange information for Security Associations with the MASH Toolkit applications.
An application-layer approach has several advantages over other IPSEC implementations: 1. Portability: Current implementations of IPSEC are limited to just a few operating systems,
such as a few specific BSD-type UNIX platforms. Additionally, the current implementations of IPSEC are in an alpha or beta release stage of software development. Although the MASH
Toolkit is also currently alpha release, it can be run on a wider variety of platforms.
2. Easy Experimentation: Developing and experimenting with application-level software is much easier than dealing with kernel-level software. Application-level software does not require privileged access to the machine. Developing kernel-level software is also time consuming because small mistakes can cause the machine to lock up and rebooting it may erase evidence of what went wrong with the software.
3. Application Specific Security: Current implementations of IPSEC provide authentication, in-tegrity, and confidentiality for all applications based on a host-wide policy. An application-layer approach allows each application to provide authentication, integrity, and confidentiality as it is needed.
4. Independent of Protocol Stack: An application-layer emulation of IPSEC allows for experi-mentation with other developing standards.
1. Protocol Header Vulnerability: The application-layer emulation does not provide authentica-tion, integrity, or confidentiality for the network and transport headers. It might be possible to duplicate some of this information at the application level, but that is not covered under the current implementation.
2. Interoperability: The application-layer emulation cannot interoperate with network-layer IPSEC implementations.
4.1
The MASH Toolkit
The application that was used for this research is the multimedia networking toolkit developed by the
MASH Project GroupI at University of California at Berkeley [15]. MASH stands for "Multimedia
Architecture that Scales over Heterogeneous environments." The multimedia networking toolkit, referred to as the MASH Toolkit, includes several applications that can be used for video, audio, or whiteboard conferencing. The central part of the MASH Toolkit, the MASH shell, can be used to easily create new applications using a scripting language.
The MASH Toolkit is designed in an object oriented fashion using a mixture of MIT Object Tcl and C++. The main two relevant classes of objects for our project are the Network objects and the Crypt objects. The Network objects are responsible for sending and receiving data. Each can use a single Crypt object to encrypt the outgoing data or to decrypt incoming data. If a Crypt object is not available, the default behavior is to send and receive data in the clear.
The main goal while implementing the IPSEC emulation in the MASH toolkit was to have minimal impact on the rest of the code base. The MASH Toolkit is still in development and the minimal impact approach will allow for easy integration of the IPSEC related code into future versions of the MASH Toolkit.
4.2
Authentication
The Authentication Header (AH) is added to data packets to provide integrity and authentication without confidentiality. The specialized Crypt object called CryptAH is responsible for adding the AH to outgoing data packets and checking the AH on incoming data packets. The CryptAH object then uses a Security Association Table object, SecAssocTbl, to keep track of the data that is part of the known Security Associations, as shown in Figure 4-1.
The AH that was used is very similar to the header specified in the IP Security protocols. There are two differences between this header format and the actual header format specified in the
1
Network ---- CryptAH
SecAssocTbl
SPI SecAssoc - AuthMD5 SPI SecAssoc [ AuthMD5
SPI SecAssoc AuthMD5 SPI SecAssoc AuthD5AuthMD5
Figure 4-1: Object diagram for CryptAH.
IPv4 Header Transport Header
Authentication Header
Payload
Figure 4-2: Format of our AH datagram.
standards. The first is the placement of the header. Since this is still at the application layer, the
AH header will come after the transport header but before the rest of the application headers and
data, as shown in Figure 4-2. Under the current implementation, this means that the information in the transport and network level headers can not be covered by the integrity or authentication
protection of the AH.
Magic Num. Length Magic Number Security Parameters Index
Authentication Data
Figure 4-3: Our AH header format.
The second difference is that the Next Protocol and Reserved fields are now used to identify that this data does include an AH header, as shown in Figure 4-3. Together these fields provide 24-bits of space that is filled with a magic number that is identified with AH in our implementation. The value of this magic number is chosen so that there will be no confusion with unauthenticated Real-time Transport Protocol [19] packets. The only time that a packet could be misidentified is if a packet is received from an unmodified application, built from the original version of the MASH toolkit, that has encryption turned on, which by default encrypts the entire payload without providing a security header. In this case, the chance that the packet will be misidentified as having an AH header is
approximately 1 out of 224
The behavior of the CryptAH object for sending a packet of data: 1. Get data packet from Network object
2. Lookup data on Security Association for sending
3. Calculate Authentication Data
4. Add new header to packet, including the SPI and Authentication Data 5. Return new data packet to Network object for sending
The behavior of the CryptAH object for receiving a packet of data: 1. Receive data packet from Network object
2. Check 24-bit AH magic number
3. If this check fails, then discard the data packet
4. Lookup data on Security Association based on SPI in header of data packet 5. If a Security Association is not found, discard the data packet
6. Remove AH header from the data packet 7. Attempt to authenticate data packet
8. If successful, return the rest of the data packet to the Network object 9. Otherwise, discard the data packet
The questionable part of the above behavior is that the CryptAH object provides no feedback to distinguish between packets rejected because the AH magic number was not present in step 3, the data did not authenticate correctly in step 9, or the SPI was just unrecognizable in step 5. If the SPI was unrecognizable, then one option would be to try to obtain the corresponding Security Association from a server. Unfortunately, this behavior is likely to leave the application open to denial of service attacks because resources are consumed for pending requests. Instead, the CryptAH object makes use of a KeyArbiter object to insure that it has all the necessary Security Associations. The design of the CryptAH object was later extended to be able to use a KeyArbiter object (see Section 4.4) to try to obtain a Security Associations. This was done in a non-blocking manner so that until an appropriate Security Association is received, the data packets will simply be discarded.
4.3
Confidentiality
The IP Encapsulating Security Payload (ESP) was added to data packets to provide confidentiality. This involved a specialized Crypt object, CryptESP, which was responsible for adding the ESP to outgoing data packets and checking the ESP header on incoming data packets. The CryptESP
Network CryptESP SecAssocTbl
SPI SecAssoc CryptDES
SPI SecAssoc -- CryptDull
SPI SecAssoc --- CryptDull
SPI
SecAssoc
CryptDES
Figure 4-4: Object diagram for CryptESP.
IPv4 Header Transport Header
ESP Header
Payload
Figure 4-5: Format of our ESP datagram.
object makes use of a Security Association Table object, SecAssocTbl, to keep track of the data that is part of the known Security Associations, as shown in Figure 4-4.
The ESP that was used is very similar to the header specified in the IP Security protocols. There are two differences between this header format and the actual header format specified in the standards. The first is the placement of the header. Since this is at the application layer, the ESP header comes after the transport header but before the rest of the application headers and data, as shown in Figure 4-5.
Magic Num. Security Parameters Index Initialization Vector
Padding Pad Let Magic Num.
Figure 4-6: Our ESP header format.
The second difference is that part of the SPI field and the Payload Type field are used to hold a 16-bit magic number that identifies the packet as containing an ESP header, as shown in Figure 4-6. This number is divided into two 8-bit parts. One of these is in the clear in the most significant byte of the SPI field (which is now only 24-bits long). The second half of this number is contained within the encrypted portion of the data packet. Again, the value of this magic number was chosen to avoid confusion with unencrypted RTP packets. The only time that a packet could be misidentified is if a packet is received from an unmodified application, built from the original version of the MASH Toolkit, that has encryption turned on. The applications built from the original MASH Toolkit will, by default, encrypt the entire payload without providing a security header. In this case, the chance
that the packet will be misidentified based on the first part of the magic number is approximately 1 out of 28. For these packets, the chance that the packet will also be misidentified after decryption is approximately 1 out of 2s.
The behavior of the CryptESP object for sending a packet of data: 1. Get data packet from Network object
2. Lookup data on Security Association for sending 3. Encrypt the data packet
4. Add new header to packet, including the SPI
5. Return new data packet to Network object for sending
The behavior of the CryptESP object for receiving a packet of data: 1. Receive data packet from Network object
2. Check first half of 16-bit ESP magic number 3. If this check fails, then discard the data packet
4. Lookup data on Security Association based on SPI in header of data packet 5. If a Security Association is not found, discard the packet
6. Remove and save the ESP header from the data packet 7. Attempt to decrypt the data packet
8. Check second half of 16-bit ESP magic number 9. If this check fails, then discard the data packet
10. If successfully decrypted, return the decrypted data packet 11. Otherwise, discard the packet
The encryption methods that are available are the Crypt objects CryptDES and CryptDULL that are part of the unmodified MASH Toolkit. CryptDULL is a simple XOR encryption scheme.
The questionable part of the above behavior is that the CryptESP object has no feedback to distinguish between data packets that did not have the ESP magic number in 3 and 9, did not decrypt correctly in step 11, or if the SPI was just unrecognizable in step 5. If the SPI was unrecognizable, then one option would be to try to obtain the corresponding Security Association from a server. Unfortunately, this behavior is likely to leave the application open to denial of service attacks
because resources are consumed for pending requests. Instead, the CryptESP object makes use of a KeyArbiter object to insure that it has all the necessary Security Associations.
The CryptESP object was later extended to be able to use a KeyArbiter object (see Section 4.4) to try to obtain Security Associations. This was done in a non-blocking manner so that until an appropriate Security Association is received, the data packets will simply be discarded.
4.4
Key Management
key vic vat mb SRM
RTP
ISAKMP I IPSEC
Figure 4-7: Security Association management architecture.
Figure 4-7 illustrates the architecture used for managing Security Associations on the host. When a datagram using either AH or ESP arrives with an unknown Security Parameters Index (SPI), the SPI is used to identify the Security Association in the local Security Association Table. When the application first starts up, it initializes the Security Association Table with all the Security Associations that are known to the local key manager application called Mashkey.
The application communicates with Mashkey via the Coordination Bus. After initializing the Security Association Table, the application continues to monitor the Coordination Bus for updates on new Security Associations and information on the invalidation of old Security Associations. Mashkey is responsible for reading in Security Associations via manual keying with a local Security Association file or via ISAKMP from a central Security Association server.
4.4.1
Security Associations
Security Associations are managed with two objects. SecAssoc objects keep track of all the informa-tion for each individual Security Associainforma-tion. SecAssocTbl objects keep track of a table of Security Associations that are indexed on the SPI of the Security Association. A SecAssocTbl object can be initialized from a file as well as dynamically modified later as Security Associations become available.
4.4.2 Mashkey
Mashkey is a program that was written using the MASH Toolkit and is designed to provide Security Associations to all locally running MASH applications. The mechanism used for exchanging Security
Associations is a Conference Bus that is built into the MASH Toolkit for this type of inter-process communication. Mashkey can read in Security Associations from a local file or it can obtain Security Associations from the Security Association Server with ISAKMP.
Mashkey provides a simple way for MASH programs to dynamically obtain Security Associations. This allows any MASH program to use Security Associations independently of how they are obtained or established. Once support for communicating with Mashkey was put into all programs built from the MASH Toolkit, they did not have to be modified to start experimenting with ISAKMP and the Security Association Server.
Within Mashkey, there exists an object called the KeyArbiter which is responsible for commu-nicating over the conference bus to other KeyArbiter objects in other applications and obtaining or transmitting Security Associations. The KeyArbiter object was embedded into the MASH Toolkit to enable CryptAH and CryptESP objects to request all Security Associations when they are initialized and to monitor the Security Association information updates as they become available.
The conference bus was assumed to be secure enough for the purposes of our experiments because it is implemented so that the information sent over the conference bus does not leave the local machine. It seems that the implementation does allow all users on a local machine to receive the messages sent on the conference bus, so security of the conference bus should be addressed at some point.
4.4.3
Security Association Server
Of the options discussed under Multicast Security, the simple approach of using a Security
Asso-ciation Database on a single Security AssoAsso-ciation Server was chosen. The main component is a UDP server which listens for requests on a well-known port. This port is different from the port specified in the Internet Draft on ISAKMP [14], so that experimentation is allowed without needing super-user privileges. This UDP server goes through the first phase of the ISAKMP exchange with each client that contacts it. After this Security Association is established, it then uses CryptAH or CryptESP objects to protect the remainder of the exchanges with that client.
The SA Server uses the Base Exchange [14], as described in Section 2.3, to establish the initial Security Association for communicating with a client. While it is processing these messages, the SA Server keeps track of the state of the negotiation with each potential client. If this state in-formation becomes stale then it is reset. The Base Exchange includes an exchange authenticating each party to each other. Although not defined yet, the authentication mechanism should be unique to each user/host pair. This will allow a security policy that allows differentiation between users running on a single host.
After the first Security Association is established for a client, the client can use this to receive information on other Security Associations. The SA Server can use the ISAKMP [14] payloads of
Notification and Delete to inform the client of what Security Associations are available as well as what Security Associations have been revoked or invalidated. For the clients use, a payload type of Request Information should be added to the list of ISAKMP payloads. This is needed because there are currently methods to send Notification or Delete payloads or to send a Request Certificate payload, but there is no method for requesting other data from the other host with ISAKMP. The Request Information payload will be used to request information on specific Security Associations or on a group of Security Associations. The message could be implemented as a variation on the Notification message because Notification allows for Domain Of Interpretation (DOI) specific data. On the SA Server, the Security Associations for communicating ISAKMP messages with clients are kept in a separate data structure from the Security Associations for use by the multicast group.
In order to inform the clients to when the new Security Associations are available or old ones have been invalidated, the SA Server can be extended to send out announcements to the multicast group. This can be done using the same multicast address if a format for the announcements is possible so that the announcements are not confused with other data. Alternatively, the SA Server could send out announcements on another multicast address that is predefined to be the control channel associated with the main multicast address. The new Security Associations will not be distributed by this means, but any client that needs to get the new Security Associations can contact the SA Server directly.
4.5
Status
Only part of the above designs were actually implemented. The CryptESP, SecAssoc, and SecAs-socTbl objects were all implemented to get a functional version of the ESP headers. The CryptAH object was not implemented, but the CryptESP object could be used as a base for developing the CryptAH object. The KeyArbiter object was written, along with the Mashkey application. The Security Association Server was only partially implemented. The Security Association Server is still a rough design and would probably need further refinement during the implementation process.
Chapter 5
Evaluation
There are two ways to measure the effectiveness of the design in Chapter 4. The first is to look at the performance of the implementation by seeing how much memory, processing time, and network bandwidth is required to use it. The second is to look at the possible security vulnerabilities introduced by using the IPSEC protocols at the application level instead of at the network level.
5.1
Performance
Of the design shown in Chapter 4, the only part what was fully implemented was confidentiality using the CryptESP object. The costs for using the CryptESP object include the memory overhead for each CryptESP object, the increase in bandwidth due to the ESP header and padding at the end of the packet, and the processing time required for using the CryptESP object on a data packet. For this analysis, the processing time due to executing code within the CryptESP object, the SecAssocTbl, or the SecAssoc objects is not going to be considered.
5.1.1
Memory Overhead
Using this object requires a constant amount of memory for the object itself plus a variable amount of memory for the SecAssocTbl. Since this memory overhead is fairly small given current technology, it is safe to ignore as long as the policy for adding new and removing old Security Associations is carefully implemented. The SecAssocTbl maintenance policy needs to control the maximum size of the SecAssocTbl. The current implementation actually uses a hash table for the SecAssocTbl. This effectively controls the maximum size, but has the side effect of a new Security Association sometimes overwriting an old, but still useful, Security Association. This was not a problem when the number of Security Associations was small, but any future work should include an explicit method for maintaining the SecAssocTbl.
Approximately 5 minutes of data sent with vic AV4 3500 ... :Me.dian .100 ... ... ... Mean = 866.41 3000 ... Stdev.=26766... S2500 8 2000 a 5 0 0 ... ... 0 0 200 400 600 800 1000 1200
Packet Size (Bytes)
Figure 5-1: vic Data Stream with Default Quality Settings
5.1.2
Bandwidth Overhead
The next step to analyzing the overhead added by using the CryptESP object is to look the packet sizes and bandwidth of example MASH Toolkit applications. The applications that were used are a video conferencing application called vic, an audio conferencing application called vat, and a whiteboard conferencing application called mb. Since vic is the application that can generally require the most network bandwidth, part of this analysis will be based on example data from a vic session. Since the bandwidth is likely to be affected the most on an application that uses many small packets, the rest of this analysis will be based on example data from a vat session. In all cases where packet sizes are examined, the data represents only the size of the application data packet and does not include the IP or UDP headers.
Shown in Figure 5-1 and Figure 5-2 are the packet size distributions for a vic video stream with the default quality settings and with high quality settings, respectively. These quality settings actually consist of several independent controls including the frame rate and the bit rate of the video stream. Each histogram is from data gathered from approximately 5 minutes worth of data being sent by vic.
Setting the video quality relatively high resulted in a slightly larger average packet size along with a smaller standard deviation. Figure 5-3 shows the histogram for the amount of data that is sent out every 100ms using vic with the high quality settings. This histogram was calculated by taking the time stamp on the first data packet and adding 100ms to it in order to get the first 100ms time block. The sizes of all the packets in this time block were then added together. This process
Approximately 5 minutes of data sent with vic 2 ... ... M edian = 967.. . .. ... ... ... :Mean = 917.04 E S... Stde .... .35 . . .. 0.5-0 0 200 400 600 800 1000 1200
Packet Size (Bytes)
Figure 5-2: vic Data Stream with High Quality Settings
was repeated for the rest of the data starting at each integral multiple of 100ms from the time of the first packet.
The average value for this histogram is 10343 bytes sent every 100ms. This value results in an average bandwidth of 827.44 kb/s. However, since the standard deviation is quite large, this can easily vary between 195.62 kb/s and 1459.2 kb/s for approximately 68.3% of the session. The same experimental data that was used in Figure 5-3 was used to synthesize the data in the histogram in Figure 5-4. This new histogram shows what the distribution of data rates would have been if
CryptESP was used to encrypt each packet.
In order to synthesize this data, 8 bytes were added to the beginning of each packet for the ESP header and 2 to 9 bytes were added to the end of each packet for the padding and the trailing fields. The amount of padding was adjusted so that the length of the encrypted section would be an integral number of 64 bit blocks that are required by DES. Using DULL as the encryption algorithm would not require this padding, but DES is the stronger and more standard encryption type of the two available. The average value for the synthesized data is 10507 bytes sent every 100ms. This value results in an average bandwidth of 840.56 kb/s. Comparing this value with the average for the original data yields an absolute increase in bandwidth of 13.12 kb/s and a relative increase in
bandwidth of 1.58%.
Shown in Figure 5-5 is the size distribution for approximately 5 minutes of a vat audio stream with the packet sizes aggregated over every 100ms. This histogram was calculated in the same way as the histogram in Figure 5-3. The encoding type that was used for the audio was DVI. DVI is one
Approximately 5 minutes of data sent with vic .... Median .= 9057 .... Mean = 10343 ....*Stdev.=. 78;7.7 . ... "500 c a 0 a) o, - 400 0), E300 8 16 0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 Size (Bytes/100ms) x 104
Figure 5-3: vic Data Stream with High Quality Settings
vic data with ESP headers
...:Median..9200.
I...
1.5 2 2.5 Size (Bytes/100ms) Mean = 10507 ... Stdev. -. 7958 ..3 ... ... ... ... ... ... 3 3.5 4 4.5 x 10Figure 5-4: Synthesized vic Data Stream with High Quality Settings
700 600 500 o S400 8 300 E 200 100 0 0 0.5
Approximately 5 minutes of data sent with vat with dvi 1500, Median = 192 Mean = 286.52 1000 ... ev.. !93.18 500 E 0 0 100 200 300 400 500 600 700 800 900 Size (Bytes/100ms)
Figure 5-5: vat Data Stream with DVI encoding
of the 8 encoding types that are available through the user interface of vat and was chosen because it produced relatively small individual packets.
The average value for this histogram is 286.52 bytes sent every 100ms, but most of the time the
sizes tended to be 96 or 480. Since the DVI encoding type uses 96 byte packets, the sizes of 96 or
480 bytes are equivalent to 1 or 5 packets being sent in that 100 ms. The average bandwidth was
23.083 kb/s. The same experimental data that was used in Figure 5-5 was used to synthesize the data in the histogram in Figure 5-6. This new histogram shows what the distribution of data rates would have been if CryptESP was used to encrypt each packet.
The data in Figure 5-6 was synthesized in exactly the same manner as the previously synthesized vic data. The average value for the synthesized data is 334.28 bytes sent every 100ms. This value results in an average bandwidth of 26.742 kb/s. Comparing this value with the average for the original data yields an absolute increase in bandwidth of 3.660 kb/s and a relative increase in bandwidth of 15.8%.
From these two examples, the impact on bandwidth of using CryptESP can be seen. For ap-plications that use relatively large packet sizes, a large amount of bandwidth, but fewer individual packets, using CryptESP results in a fairly large absolute change but a small relative change. For applications that use relatively small packet sizes, a small amount of bandwidth, but more individual packets, using CryptESP results in a small absolute change but a large relative change.
vat with dvi with ESP headers 1500 Median 224 .Mean = 334.28 S 1000 S...tdev = 2 ,37. .0 . . .. ... .... . .... . .. ... . . . E 0 100 200 300 400 500 600 700 800 900 1000 1100 Size (Bytes/100ms)
Figure 5-6: Synthesized vat Data Stream with DVI encoding
5.1.3
Encryption Processing Overhead
The processing overhead that is going to be analyzed is the approximate time necessary to encrypt and decrypt packets of various sizes using the two available encryption algorithms. The application-level ESP header that is added to the payload does not impact the processing overhead for encryption. However, the padding and the two trailing fields, shown in Figure 4-5, do change the size of the data that must be encrypted on a per packet basis.
The two encryption algorithms were DES and DULL (basic xor encryption). Shown in Figure 5-7 is the processing time required for encrypting a range of packet sizes using the implementation of DES for the MASH Toolkit. This data was obtained from two different computers. The upper line in the figure represents the time spent on encryption by one of the slowest SparcStations in the lab. The lower line in the figure represents the time spent on encryption by one of the fastest SparcStations in the lab. Since the processing required for decrypting is approximately the same as for encrypting, only the encryption is going to be considered.
The range of 1 to 2000 bytes is sufficient to cover the packet sizes that are used by the MASH Toolkit. The slight inconsistency in the data for the slower computer, shown in Figure 5-7, has not been fully explained but does not affect the rest of this analysis. Figure 5-7 is actually composed of data points from buffer sizes of an integral number of 64 bit blocks. DES encrypts and decrypts only in 64 bit blocks. The result of this is that each buffer that needs to be encrypted must be padded to the next 64 bit boundary and each buffer that needs to be decrypted must be an integral number
Encryption with DES 8 1500-.2 E 0 5000 200 400 600 800 1000 1200 1400 1600 1800 2000
Buffer Size (Bytes)
Figure 5-7: Encryption with DES
Shown in Figure 5-8 is the processing time required for encrypting a range of packet sizes using the DULL algorithm in the MASH Toolkit. This data was collected with the same computers that were used for the data on the DES algorithm.
The DULL algorithm does not require a specific block size for encryption or decryption. For both DES and DULL, the packet size and processing time were linearly related. The measurements indicate that the constant overhead for each call made to the encrypt or decrypt routines is minimal and can be discounted in the rest of the analysis.
If DULL is used as the encryption algorithm, the amount of processing that is done for en-cryption is minimal and the no padding needs to be added for the enen-cryption. Because of this, using CryptESP with the DULL algorithm is very similar to using the DULL algorithm directly without the application-level ESP header. Using the data from the vat session shown in Figure 5-5, the packet size is 96 bytes. If this packet is encrypted with DULL, this will take between 3 and 5 microseconds of CPU time. Once the padding and trailing fields from the CryptESP object are added, the packet size is 104 bytes and the time required for encryption will increase by less than 1 microsecond.
Since DES requires a 64 bit block size, using CryptESP with DES can potentially add an ad-ditional block to each packet. Using the data from the vat session, the packet size of 96 bytes will take between 61 and 101 microseconds to encrypt. Once the padding and trailing fields are added, the packet size of 104 bytes will take between 69 and 112 microseconds to encrypt. This represents a 10.9% to 13.1% increase in encryption time due to using CryptESP with DES instead of using
Encryption with DULL 60 20 10 0 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Buffer Size (Bytes)
Figure 5-8: Encryption with DULL
DES directly. This percentage will decrease with larger packet sizes because the potential one block increase will be smaller compared to the total packet size
5.2
Security Analysis
The IPSEC protocols were originally designed to be used to provide security to IP datagrams. Using these protocols at the application-level provides security to the application. However, this will not protect the data that is present in the network-level or transport-level headers. Most of these vulnerabilities are not present or are minimized in the standard IPSEC protocol. The vulnerability of the exposed network-level and transport-level headers can be exploited through a few well known ways. In order to help minimize these vulnerabilities, there are a few modifications that could be made to the application-level emulation.
5.2.1
Exploiting Vulnerabilities
The specific headers that are relevant to this application-level emulation of IPSEC are the IP header [18] and the UDP header [17]. The IP header includes fields for the source address, des-tination address, the total packet length, and various fields used while the packet is in transit. The UDP header includes fields for the source port, the destination port, the packet length, and the checksum of the packet.
* Denial of Service attacks
* Replay attacks * Cut and Paste attacks
Denial of Service (DOS) attacks are generally the hardest to defend against. The minimum goal of DoS attacks is to get the target machine to spend more than the usual amount of time processing the attackers packets. The more successful DoS attacks sometimes can disable or crash the target machine simply by sending it certain packets.
At least one form of a DoS attack on the application-level emulation is to send a packet of garbage data with an AH or ESP header to the target machine. Since the AH or ESP header is present, the target machine will spend at least some processing time on this packet. This small amount of time can be exaggerated by flooding the target machine with these garbage packets. The only necessary information is the target port on the target machine that a MASH Toolkit application is listening to. If the processing time is significant, the target machine will be rendered effectively unusable.
Replay attacks consist of an attacker simply replaying a captured packet. Since UDP is not connection based, all UDP packets received for a certain port will be given to the application that is receiving packets from that port. The results of a replayed packet will vary depending on the application. If the application is video conferencing, then the replayed packet could corrupt part or all of a frame. If the application is whiteboard conferencing, then an extra object might be drawn on the target machine's whiteboard. The effects might be more drastic by flooding the target machine with replayed packets. This would result in another DoS attack. This vulnerability may also be present in a standard IPSEC implementation depending on what version of the RFCs or Internet Drafts the implementation is based on.
Cut and Paste attacks consist of an attacker combining multiple captured packets to form a new packet to send to the target machine. The attacker uses two packets with the same SPI value in the ESP or AH header to form a new packet that has partial data from both of the original packets. This packet will be intially accepted by the target machine and will be decrypted or authenticated. If the packet is only encrypted, with typical block encryption algorithms, like DES, this will result in a little bit of garbage data around where the two packets were spliced together. However, the rest of the data should be formated correctly for the application. This has the potential of letting the attacker create new data packets which may be accepted by the application long enough to cause incorrect behavior. In an extreme case, this attack could become another DoS attack because the application may crash and leave the target machine in an unusable state. If the packet is authenticated, using AH, the cut and paste attack will always fail because the authentication algorithm will fail and the packet will always be discarded.
