An Application Level Emulation of ... Chad F. Jones
advertisement
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........... .. :........... .. .:.... .... . . . . . . . . . . .. .. . .. . . . .... Dr. Thomas M. Parks MIT Lincoln Laboratory Thesis Supervisor Certified by ................. , ..... . .. .... .. ........ ..... ........ Dr. Clifford J. Weinstein MIT Lincoln Laboratory Thesis Supervisor - Accepted by...... MASSACHUSETTs INSTIr .'r OF TECHiN,~ ,"-• JUL 141f8 l LIBRARIES .......... : Gradt tUhur C. Smith ommittee-..on" ...... S Chairman, Department Committee on Graduate Theses Departmen -.. 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 9 IP Security 2.1 Authentication and Integrity 2.2 Confidentiality 2.3 Key Management ................... ... 2.4 Related Work ................... .................. ................... .. ..... ... 9 . ................... ................... 11 .. .............. . . 3 Multicast Security 4 13 14 3.1 Authentication 3.2 Key Management ................... ................... ................... ... . .............. .. 14 15 3.2.1 Repeated Two-Party Exchange ................... ....... 15 3.2.2 Security Association Database ....... 15 3.2.3 Multi-Party Exchange ................... 3.2.4 Managing Dynamic Group Membership ................... ................... ........... 16 .. 16 Design and Implementation 17 4.1 The MASH Toolkit ............. 4.2 Authentication ................... ................... . 18 4.3 Confidentiality ................... ................... . 20 4.4 Key Management ................... 4.5 5 10 ...... ........... ... 4.4.1 Security Associations ................... 4.4.2 Mashkey ................... 4.4.3 Security Association Server ................... Status ................... ....... .............. 18 .. ............ 23 ................... ....... .................. ...... 23 . 24 26 Performance ................... 5.1.1 . 25 Evaluation 5.1 23 Memory Overhead ................... ................... ... ........... 26 .. 26 5.2 6 5.1.2 Bandwidth Overhead ................... 5.1.3 Encryption Processing Overhead ................... ............ Security Analysis ................... ...... 31 ............... 5.2.1 Exploiting Vulnerabilities ................... 5.2.2 Hardening Application-level IPSEC Conclusions 27 ................... .. ........ 33 . .... 33 35 37 List of Figures 1-1 Security protocols above the transport layer. 2-1 Format of an AH datagram . 2-2 AH header format . 2-3 Format of an ESP datagram in tunnel mode. 2-4 Format of an ESP datagram in transport mode. ........... ................ 2-5 Encapsulating Security Payload header format. 2-6 ISAKMP Header . ................ 4-1 Object diagram for CryptAH... 4-2 Format of our AH datagram. 4-3 Our AH header format...... 4-4 Object diagram for CryptESP. 4-5 Format of our ESP datagram. . 4-6 Our ESP header format. ...... 4-7 Security Association management architecture. 5-1 vic Data Stream with Default Quality Settings ..... 5-2 vic Data Stream with High Quality Settings ....... 5-3 vic Data Stream with High Quality Settings ....... 5-4 Synthesized vic Data Stream with High Quality Settings 5-5 vat Data Stream with DVI encoding . 5-6 Synthesized vat Data Stream with DVI encoding . 5-7 Encryption with DES 5-8 Encryption with DULL ................... .......... .................. . . Chapter 1 Introduction The goal of this thesis is to explore some of the issues associated with secure IP multicast [7]. Multimedia 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 transmissions. 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. Security 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 experimentation with secure multicast. Since current IPSEC implementations 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 modified 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 SSL I TCP I ? I 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]. Revisions 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 Association. 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 confidentiality. 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 IPv4 Header Authentication Header Transport Header Payload 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 Yi N modified and can rely on the gateways to provide confidentiality for all of the datagrams. IPv4 Header ESP Header Transport Header Payload 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 c 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 will start with the ISAKMP Header, shown in Figure 2-6. Initiator Cookie Responder Cookie 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 exchange 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 proposals (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, DiffieHellman, 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 * 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 functionality 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 IPSEC 2 is available for Linux for the University of Arizona's x-kernel 3 . The x-kernel is an object-based framework for implementing network protocols. The Naval Research Labs released an alpha version IPv6 with IPSEC 4 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. Whenever 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 distributed 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. privileged access to the machine. Application-level software does not require 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, integrity, 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 experimentation with other developing standards. An application-layer approach does have a few disadvantages as well: 1. Protocol Header Vulnerability: The application-layer emulation does not provide authentication, 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 Group I 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 <http://mash.cs.berkeley.edu> Network CryptAH ---- SecAssocTbl - AuthMD5 [ AuthMD5 SPI SPI SecAssoc SecAssoc SPI SecAssoc AuthMD5 SPI SecAssoc AuthD5 AuthMD5 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 CryptDES SPI SecAssoc SPI SecAssoc -- SPI SecAssoc --- SPI SecAssoc CryptDull CryptDull 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 information for each individual Security Association. 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 communicating 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 Association Database on a single Security Association 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 information 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 SecAssocTbl 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 82000 a 500 0 ........... 0 200 .............. 400 600 Packet Size (Bytes) 800 1000 1200 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 x104 2... . .. ........ Median = 967.. .......... ............... ........... :Mean = 917.04 E S... Stde .... . 35 . . .. 0.5- 0 0 200 400 600 Packet Size (Bytes) 800 1000 1200 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 . ... c"500 a 0 a) -o,400 0) , E300 8 16 0 0.5 1 1.5 2 2.5 Size (Bytes/100ms) 3 4 3.5 4.5 x 104 Figure 5-3: vic Data Stream with High Quality Settings vic data with ESP headers 700 .....................:Median..9200. 600 Mean = 10507 ........... 500 Stdev. -. 7958 ..3 ... o S400 ..... . ....... ..... ....... ........ I..... 8 300 E 200 100 0 0 0.5 1.5 2 2.5 Size (Bytes/100ms) 3 3.5 4 4.5 x 10 Figure 5-4: Synthesized vic Data Stream with High Quality Settings Approximately 5 minutes of data sent with vat with dvi 1500, Median = 192 Mean = 286.52 ev.. ...... 1000 !93.18 500 E 0 0 100 200 300 400 500 600 Size(Bytes/100ms) 700 800 900 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 is286.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 applications 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 = 2 ,37. S.........tdev S 1000 . 0 . . .. ... ..... ..... .. ... . .. E 0 100 200 300 400 500 600 700 Size (Bytes/100ms) 800 900 1000 1100 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 applicationlevel 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 of 64 bit blocks. Encryption with DES 8 1500.2 E 5000 0 200 400 600 800 1000 1200 Buffer Size (Bytes) 1400 1600 1800 2000 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 encryption is minimal and the no padding needs to be added for the encryption. 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 additional 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 Buffer Size (Bytes) 1400 1600 1800 2000 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, destination 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. The three attacks that are going to be examined are: * 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. One variation on the cut and paste attack would be for the attacker to simply truncate a captured packet to only include the AH or ESP header. If the packet included an AH header, the truncated packet will be rejected when the authentication fails. If the packet included only an ESP header, the decryption may succeed when the length of the encrypted data is zero. Whether or not this type of truncated packet will be passed onto the rest of the application is implementation dependent. The application-level implementation, described in Section 4.3, requires a minimum data length for minimal padding and a magic number field. This design ensures that any truncated packets will be rejected. All of these attacks might be further augmented by spoofing the source address on the packets sent to the target machine. Spoofing is the practice of putting a source IP address in the IP header that does not correspond to the sending machine. The result is that return packets can not be sent to the the sender, but that will not usually happen directly with multicast applications. Also, since the source address is not valid, the target machine usually can not determine where the attacker is even if the attack is detected. 5.2.2 Hardening Application-level IPSEC In order to help protect against these attacks, and potentially against other attacks, the following changes should be made to the application-level emulation of IPSEC: * Use Available IP and UDP information in AH calculation * Include Sequence Numbers in AH The first change that should be made is to expand the AH calculation to include information that is normally in the IP and UDP headers. This should include the source address, the destination address, the source port, and the destination port. All of this information is available to the application prior to sending a packet as well as immediately after receiving a packet. This information should be concatenated with the buffer to be sent in order to calculate the authentication data. On the receiving host, this data can be verified in a similar manner. This change will not require larger packets and thus will not affect the bandwidth required. This change will slightly increase the time necessary to calculate the authentication data for a packet. Including IP and UDP information in the AH calculation will protect against IP spoofing. Simply including the AH on all packets will also protect against cut and paste attacks. The UDP checksum information does not have to be included because an invalid checksum will result in the packet being discarded before it reaches the application and the application can use the AH header, with a crytographics checksum, to ensure that the packet has not been modified. The next change that could be made is to add a sequence number to the AH used by CryptAH. Adding sequence numbers to AH headers will prevent the replay attacks discussed in the previous section. This new field should be inserted according to the recent Internet Draft on the IP Authentication Header [10]. Each Security Association will have a counter for the sequence numbers so that the replay of old packets can be detected. Since some sequence numbers may be lost or delayed in transit, each receiver should gracefully handle out of order sequence numbers within a constant window. This will allow the detection of replayed packets by the application-level IPSEC implementation while still allowing packets to be received out of order and for some to be lost entirely. The applications used for the performance evaluation in Section 5.1 actually use their own sequence numbers, or the equivalent, to discard replayed packets. However, relying on the application for this functionality will require more processing time for packets that will just be discarded and detecting replayed packets is useful for all application. In a multicast environment, sequence numbers can potentially cause a problem because each host in the multicast group will probably be on a different sequence number for the data it is personally sending. In order for sequence numbers to be useful, the Security Associations must be setup so that there is only one host that sends packets using a given Security Association. As discussed in Section 3.1, this should already be the case if AH is expected to be used in a multicast environment. The separate Security Associations will allow each receiving host to store the last received sequence number from a single sending host of that Security Association. After these changes are made, the application-level emulation is approximately as secure as the original IPSEC protocols against attack. This is mostly the result of making the authentication mechanisms stronger. The only additional overheads, compared to the design in Chapter 4, were slightly more computation for the AH data and the slight increase in bandwidth for sequence numbers in the AH. These overheads should now match a network-level implementation. Unfortunately, the application-level emulation will never be able to provide confidentiality directly to the UDP header fields including the UDP port numbers and the length of the packet. However, if extra padding is added to the packet before it is sent, the UDP length will only reveal the maximum possible length of the data. Chapter 6 Conclusions By developing an application-layer emulation of IPSEC and designing key management applications that use ISAKMP, practical experience has been gained and experiments have been done with secure IP multicast. This application-layer emulation has proven to be portable and easy to experiment with. Additionally, it has been shown that the application-level implementation behaves similarly to standard implementations. Experiments with the ESP part of the application-layer emulation of IPSEC allowed measurements and calculations of the bandwidth and processing overhead incurred for transmitting secure multicast video and audio sessions. The bandwidth and processing costs varied depending on which application was being used and how the application was being used. The security implications of the application-layer emulation were also analyzed relative to the standard IPSEC protocols. By adding a few fields to the AH data calculation and adding a sequence number field to the AH, the application-layer emulation can be made as secure as the IPSEC protocols as far as authentication. However, it is impossible to ever provide confidentiality directly to the transport-level headers. Bibliography [1] Randall Atkinson. IP authentication header. Request for Comments 1826, IETF Network Working Group, August 1995. <ftp://ds.internic.net/rfc/rfcl826.txt>. [2] Randall Atkinson. IP encapsulating security payload. Request for Comments 1827, IETF Network Working Group, August 1995. <ftp://ds.internic.net/rfc/rfc1827.txt>. [3] Randall Atkinson. Security architecture for the internet protocol. Request for Comments 1825, IETF Network Working Group, August 1995. <ftp://ds.internic.net/rfc/rfc1825.txt>. [4] A. Ballardie. Scalable multicast key distribution. Request for Comments 1949, IETF Network Working Group, May 1996. <ftp://ds.internic.net/rfc/rfc1949.txt>. Architecture. Internet draft, IETF Inter-Domain Multicast Routing Working Group, February 1996. <ftp://ds.internic.net/ [5] Anthony J. Ballardie. Core based trees multicast: internet-drafts/draft-ietf-idmr-cbt-arch-03.txt>. [6] Anthony J. Ballardie, Scott Reeve, and Nitin Jain. Core based trees multicast: Protocol specification. Internet draft, IETF Inter-Domain Multicast Routing Working Group, April 1996. <ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-spec-05.txt>. [7] S. Deering. Host extensions for IP multicasting. Request for Comments 1112, IETF Network Working Group, August 1989. <ftp://ds.internic.net/rfc/rfcll1112.txt>. [8] Chad Jones, Thomas Parks, and Clifford Weinstein. Experiments with Secure IP Multi- cast. Submitted to 5th ACM Conference on Computer and Communications Security <http:// www.sst.ll.mit.edu/Projects/p535/publications/ccs98/>, April 1998. [9] Phil Karn, Perry Metzger, and William Allen Simpson. The ESP DES-CBC transform. Request for Comments 1829, IETF Network Working Group, August 1995. <ftp://ds.internic.net/rfc/ rfc1829.txt>. [10] Stephen IETF Kent and Network Randall Atkinson. Working Group, draft-ietf-ipsec-auth-header-06.txt>. May IP authentication 1998. header. Internet draft, <http://www.ietf.org/internet-drafts/ [11] Stephen Kent and Randall Atkinson. IP encapsulating security payload. draft, IETF Network Working Group, March 1998. Internet <http://www.ietf.org/internet-drafts/ draft-ietf-ipsec-esp-v2-04.txt>. [12] Stephen Kent and Randall Atkinson. Security architecture for the internet protocol. Internet draft, IETF Network Working Group, March 1998. <http://www.ietf.org/internet-drafts/ draft-ietf-ipsec-arch-sec-04.txt>. [13] J. Kohl and C. Neuman. The kerberos network authentication service (v5). Request for Comments 1510, IETF Network Working Group, September 1993. <ftp://ds.internic.net/rfc/ rfcl510.txt>. [14] Douglas Maughan, Mark Schertler, Mark Schneider, and Jeff Turner. Internet security association and key management protocol. Internet draft, IETF IP Security Protocol Working Group, March 1998. <http://www.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt>. [15] Steven McCanne, Eric Brewer, Randy Katz, Lawrence Rowe, Elan Amir, Yatin Chawathe, Alan Coopersmith, Ketan Mayer-Patel, Suchitra Raman, Angela Schuett, David Simpson, Andrew Swan, Teck-Lee Tung, David Wu, and Brian Smith. Toward a common infrastructure for multimedia-networking middleware. In International Workshop on Network and Operating Systems Support for Digital Audio and Video, St. Louis, Missouri, May 1997. <http:// www-mash.cs.berkeley.edu/dist/mash/papers/mash-nossdav97.ps.gz>. [16] Perry Metzger and William Allen Simpson. IP authentication using keyed MD5. Request for Comments 1828, IETF Network Working Group, August 1995. <ftp://ds.internic.net/rfc/ rfc1828.txt>. [17] J. Postel. User datagram protocol. Request for Comments 768, Internet Engineering Task Force, August 1980. <ftp://ds.internic.net/rfc/rfc768.txt>. [18] J. Postel. Internet protocol. Request for Comments 791, Internet Engineering Task Force, September 1981. <ftp://ds.internic.net/rfc/rfc791.txt>. [19] Henning Schulzrinne, Stephen L. Casner, Ron Frederick, and Van Jacobson. RTP: A transport protocol for real-time applications. Request for Comments 1889, IETF Audio-Video Transport Working Group, January 1996. <ftp://ds.internic.net/rfc/rfcl889.txt>.
